Introduction to CRS does not cover non-geographic cases #392

Open
6a6d74 opened this Issue Oct 5, 2016 · 4 comments

Projects

None yet

4 participants

@6a6d74
Contributor
6a6d74 commented Oct 5, 2016

Best Practice scope is "spatial data" - which includes non-geographic location (e.g. where things aren't positioned relative to the Earth). For example, we have a microscopy use case where the locations of cells are described.

@lvdbrink lvdbrink added the bp label Jan 25, 2017
@KerryLea
Contributor
KerryLea commented Mar 1, 2017

Also, ssn uses the notion of relative location (inherited from sensorml) for enabling Sensors to be located in space relative to their Platforms (which in turn might be located according to a geographic CRS). However, ssn does not say how to encode this relationship so it would be nice to refer to BP for relative locations. Having said that, it is not fundamentally necessary and I don't have a firm proposal, either.

This use case might also apply to sosa (ssn core) , but that is unclear to me.

@dr-shorthair
Contributor

Strictly all locations are relative. Its just that for some the reference frame is geodetic, and for others the reference frame is local. The ISO coordinate reference system standard refers to non-geodetic frames as 'engineering coordinate reference systems' since they are commonly used in engineering contexts.

@lvdbrink
Contributor
lvdbrink commented Mar 17, 2017 edited

http://w3c.github.io/sdw/bp/#relative-position now talks about this. However, this issue is related to Section 8. Coordinate Reference Systems but whether relative positioning should be added to the intro is debatable imho.

@lvdbrink
Contributor
lvdbrink commented Apr 5, 2017

Discussion on the mailing list suggests we should be clear about when we're talking about spatial vs geospatial data. Also, Martian spatial data was mentioned.

@6a6d74 6a6d74 self-assigned this Apr 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment