Introduction to CRS does not cover non-geographic cases #392
|
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. |
|
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. |
|
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. |
|
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. |
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.