Spatial values
Cypher^{®} has builtin support for handling spatial values (POINT
values), which can be stored as properties on nodes and relationships in Neo4j databases.
This section begins with an explanation of the POINT
type.
It then proceeds to discuss Cypher’s support of Coordinate Reference Systems, and how to work with spatial instants in Cypher, including how spatial point instants work with Cypher indexing.
Finally, it briefly explains comparability and orderability with regard to spatial instants.
For more information about spatial functions, allowing for the creation and manipulation of spatial values, see the section on Spatial functions. For more information about the comparison and ordering of spatial values, see the section on the ordering and comparison of values. 
The POINT type
Neo4j supports the POINT
type for values of spatial geometry.
Values with the POINT
type have the following characteristics:

Each point can have either 2 or 3 dimensions. This means it contains either 2 or 3 64bit
FLOAT
values, which together are called the Coordinate. 
Each point will also be associated with a specific Coordinate Reference System (CRS) that determines the meaning of the values in the Coordinate.

Instances of
POINT
andLIST<POINT>
can be assigned to node and relationship properties. 
Nodes and relationships with
POINT
orLIST<POINT>
properties can be indexed using a point index. This is true for all CRSs (and for both 2D and 3D). 
The distance function will work on points in all CRS and in both 2D and 3D, but only if the two points have the same CRS (and therefore also same dimension).
Coordinate Reference Systems
Four Coordinate Reference Systems (CRS) are supported, each of which falls within one of two types: geographic coordinates, modeling points on the earth, or Cartesian coordinates, modeling points in euclidean space:
Data within different coordinate systems are entirely incomparable, and cannot be implicitly converted from one to the other. This is true even if they are both Cartesian or both geographic but of a different dimension. For example, if you search for 3D points using a 2D range, you will get no results. However, they can be ordered, as discussed in more detail in the section about ordering and comparison of values.
Geographic coordinate reference systems
Two Geographic Coordinate Reference Systems (CRS) are supported, modeling points on the earth:


A 2D geographic point in the WGS 84 CRS is specified in one of two ways:

longitude
andlatitude
(if these are specified, and thecrs
is not, then thecrs
is assumed to beWGS84
). 
x
andy
(in this case thecrs
must be specified, or will be assumed to be Cartesian).


Specifying this CRS can be done using either the name 'wgs84' or the SRID 4326 as described in point()  WGS 84 2D.



A 3D geographic point in the WGS 84 CRS is specified one of in two ways:

longitude
,latitude
and eitherheight
orz
(if these are specified, and thecrs
is not, then thecrs
is assumed to beWGS843D
). 
x
,y
andz
(in this case thecrs
must be specified, or will be assumed to be Cartesian3D).


Specifying this CRS can be done using either the name 'wgs843d' or the SRID 4979 as described in point()  WGS 84 3D.

Converting coordinate units
The units of the latitude
and longitude
fields are in decimal degrees, and need to be specified as floating point numbers using Cypher literals.
It is not possible to use any other format, such as 'degrees, minutes, seconds'.
The units of the height
field are in meters.
When geographic points are passed to the distance function, the result will always be in meters.
If the coordinates are in any other format or unit than those supported, it is necessary to explicitly convert them.
For example, if the incoming $height
is a string field in kilometers, it would be necessary to add height: toFloat($height) * 1000
to the query.
Likewise if the results of the distance
function are expected to be returned in kilometers, an explicit conversion is required.
The below query is an example of this conversion:
WITH
point({latitude: toFloat('13.43'), longitude: toFloat('56.21')}) AS p1,
point({latitude: toFloat('13.10'), longitude: toFloat('56.41')}) AS p2
RETURN toInteger(point.distance(p1, p2)/1000) AS km
km 


Rows: 1 
Cartesian coordinate reference systems
Two Cartesian Coordinate Reference Systems (CRS) are supported, modeling points in euclidean space:


A 2D point in the Cartesian CRS is specified with a map containing
x
andy
coordinate values 
Specifying this CRS can be done using either the name 'cartesian' or the SRID 7203 as described in point()  Cartesian 2D



A 3D point in the Cartesian CRS is specified with a map containing
x
,y
andz
coordinate values 
Specifying this CRS can be done using either the name 'cartesian3d' or the SRID 9157 as described in point()  Cartesian 3D)

The units of the x
, y
, and z
fields are unspecified.
This means that when two Cartesian points are passed to the distance
function, the resulting value will be in the same units as the original coordinates.
This is true for both 2D and 3D points, as the Pythagoras equation used is generalized to any number of dimensions.
However, just as you cannot compare geographic points to Cartesian points, you cannot calculate the distance between a 2D point and a 3D point.
If you need to do that, explicitly transform the one type into the other.
For example:
WITH
point({x: 3, y: 0}) AS p2d,
point({x: 0, y: 4, z: 1}) AS p3d
RETURN
point.distance(p2d, p3d) AS bad,
point.distance(p2d, point({x: p3d.x, y: p3d.y})) AS good
bad  good 



Rows: 1 
Spatial instants
All POINT
types are created from two components:

The Coordinate containing either 2 or 3
FLOAT
values (64bit). 
The Coordinate Reference System (or CRS) defining the meaning (and possibly units) of the values in the Coordinate.
For most use cases, it is not necessary to specify the CRS explicitly as it will be deduced from the keys used to specify the coordinate. Two rules are applied to deduce the CRS from the coordinate:

Choice of keys:

If the coordinate is specified using the keys
latitude
andlongitude
the CRS will be assumed to be Geographic and therefor eitherWGS84
orWGS843D
. 
If instead
x
andy
are used, then the default CRS would beCartesian
orCartesian3D
.


Number of dimensions:

If there are 2 dimensions in the coordinate,
x
&y
orlongitude
&latitude
the CRS will be a 2D CRS. 
If there is a third dimensions in the coordinate,
z
orheight
the CRS will be a 3D CRS.

All fields are provided to the point
function in the form of a map of explicitly named arguments.
Neo4j does not support an ordered list of coordinate fields because of the contradictory conventions between geographic and cartesian coordinates, where geographic coordinates normally
list y
before x
(latitude
before longitude
).
The following query which returns points created in each of the four supported CRSs.
Take particular note of the order and keys of the coordinates in the original point
function, and how those values are displayed in the results:
RETURN
point({x: 3, y: 0}) AS cartesian_2d,
point({x: 0, y: 4, z: 1}) AS cartesian_3d,
point({latitude: 12, longitude: 56}) AS geo_2d,
point({latitude: 12, longitude: 56, height: 1000}) AS geo_3d
cartesian_2d  cartesian_3d  geo_2d  geo_3d 





Rows: 1 
For the geographic coordinates, it is important to note that the latitude
value should always lie in the interval [90, 90]
.
Any other value outside this range will throw an exception.
The longitude
value should always lie in the interval [180, 180]
.
Any other value outside this range will be wrapped around to fit in this range.
The height
value and any Cartesian coordinates are not explicitly restricted.
Any value within the allowed range of the signed 64bit floating point type will be accepted.
Components of points
Components of POINT
values can be accessed as properties.
Component  Description  Type  Range/Format  WGS84  WGS843D  Cartesian  Cartesian3D 


The first element of the Coordinate 

Number literal, range depends on CRS 


The second element of the Coordinate 

Number literal, range depends on CRS 


The third element of the Coordinate 

Number literal, range depends on CRS 


The first element of the Coordinate for geographic CRSs, degrees East of the prime meridian 

Number literal, 


The second element of the Coordinate for geographic CRS, degrees North of the equator 

Number literal, 


The third element of the Coordinate for geographic CRSs, meters above the ellipsoid defined by the datum (WGS84) 

Number literal, range limited only by the underlying 64bit floating point type 


The name of the CRS 

One of 


The internal Neo4j ID for the CRS 

One of 
Examples
The following query shows how to extract the components of a Cartesian 2D POINT
value:
WITH point({x: 3, y: 4}) AS p
RETURN
p.x AS x,
p.y AS y,
p.crs AS crs,
p.srid AS srid
x  y  crs  srid 





Rows: 1 
The following query shows how to extract the components of a WGS84 3D POINT
value:
WITH point({latitude: 3, longitude: 4, height: 4321}) AS p
RETURN
p.latitude AS latitude,
p.longitude AS longitude,
p.height AS height,
p.x AS x,
p.y AS y,
p.z AS z,
p.crs AS crs,
p.srid AS srid
latitude  longitude  height  x  y  z  crs  srid 









Rows: 1 
Spatial values and indexes
If there is a RANGE or POINT index on a particular node or relationship property, and a spatial point is assigned to that property on a node or relationship, the node or relationship will be indexed.
In a POINT index, Neo4j uses space filling curves in 2D or 3D over an underlying generalized B+Tree. This index has support for equality, distance, and bounding box queries.
In a RANGE index, the points will be sorted according to their lexicographic ordering per coordinate reference system. For point values, this index has support for equality.
Comparability and orderability
Cypher does not support comparing spatial values using the inequality operators, <
, <=
, >
, and >=
.
Attempting to do so will return null
.
To compare spatial points within a specific range, instead use the spatial functions point.distance or point.withinBBox.