Clarification on the semantics of POINT

[aanastasiou]

I am looking at the point data type and I can see that it uses x,y,z and longitude,latitude,height interchangeably so I was wondering what is the intention behind this.

I can see from the documentation that the intention seems to be to discriminate between points on an ellipsoid to points on a plane in general.

However, it is possible to create WGS-84 points with x,y attributes and cartesian points with longitude, latitude attributes which would make the distinction more of an "alias", rather than a strict type checking one.

I think that the distinction between geographical and "generic" points would be useful although it does not seem to be enforced right now.

Can you please clarify if this is an alias or is meant to be more strictly associated with the data type?

EDIT: No, entirely my bad, the semantics of POINT are clear right now

[david_allen]

Following up on this for others later - the coordinate reference systems with geospatial points (like WGS843D vs. Cartesian) are quite important, and do totally change the semantics of what a point means, because they are sort of like different languages for talking about geospatial things.

In fact if people try it out, and you try to compute the distance between a WGS843D point and a cartesian point, the answer will always come back null. It's not that there isn't a distance between these two points, but that their underlying semantics are so different the answer of the distance between them wouldn't be meaningful.

Usually I advise people to pick a single CRS and stick with it for these reasons. In this case, the semantics of the point will be dictated by the CRS, and for that you need the documentation which is on the site.

[aanastasiou]

Thank you for your reply. I think that the confusion originally stemmed from simple CREATE node tests which seemed to go ahead without problems but were however wrong on my part. This has been rectified and a first iteration of POINT support has been put together for neomodel.

Geospatial points are geospatial points and geometric points are geometric points and any attempt to instantiate one as the other fails. And this is great for datatypes and validation.

If there is anything remaining from this "issue" at the moment, I would say it is the distinction in just two things and a minor discrepancy between the API and the backend:

1. Right now, neo4j.v1.spatial seems to be creating two separate points when points can be expressed in a multitude of projections. So, I believe that the design will converge to a more encompassing solution. I haven't yet tried saving an "absurd" WGS-84 point to check if it will fail but I am thinking of incorporating validation of coordinates against the CRS in the OGM POINT type. This can be extended to any CRS of course.

2. The other thing that I noticed was that POINT had srid as the attribute but not crs. srid is not descriptive enough (being just a number) and in any case, it is possible to define point using the CRS on a CYPHER query. So, I would expect that crs would be available as an attribute, even if via a simple dictionary mapping.

But in the bigger picture, I think that these are details. We might have to adjust the code in the near future but overall, the basic functionality of POINT works just fine.

All the best