Home › Forums › General Feedback › navigation.position format
This topic contains 1 reply, has 2 voices, and was last updated by Paul Sumpner 2 years, 9 months ago.
-
AuthorPosts
-
March 26, 2018 at 1:34 pm #858
I’m doing an app, and I’m wondering why the SignalK navigation.position entries have a different “Value” schema compared to the other entries.
Here’s the navigation.position entry:
{“context”: “vessels.urn:mrn:signalk:uuid:53353100-4e4e-4a4b-3230-333037323031″,”updates”:[
{“source”:{“type”: “NMEA0183″,”talker”: “GN”,”sentence”: “RMC”,”label”: “N0183-01″},”timestamp”: “2018-03-21T18:50:31Z”,
“values”:[{“path”: “navigation.position”,”value”:{“longitude”: 11.501361,”latitude”: 57.763695}}]}]}If the values field of navigation.position followed the schema of the other entries if would look something like:
“values”:[{“path”: “navigation.position.longitude”,”value”: 11.501361},{“path”: “navigation.position.latitude”,”value”: 57.763695}]One example of the normal formatting is here: (COG and SOG)
{“context”: “vessels.urn:mrn:signalk:uuid:53353100-4e4e-4a4b-3230-333037323031″,”updates”:[
{“source”:{“type”: “NMEA0183″,”talker”: “GN”,”sentence”: “RMC”,”label”: “N0183-01″},”timestamp”: “2018-03-21T18:50:31Z”,
“values”:[{“path”: “navigation.courseOverGroundTrue”,”value”: 0.000000},{“path”: “navigation.speedOverGround”,”value”: 0.005144}]}]}Another normal example is here: (AWS, AWA)
{“context”: “vessels.urn:mrn:signalk:uuid:53353100-4e4e-4a4b-3230-333037323031″,”updates”:[
{“source”:{“type”: “NMEA0183″,”talker”: “II”,”sentence”: “MWV”,”label”: “N0183-00″},”timestamp”: “1970-01-15T08:23:28.922Z”,
“values”:[{“path”: “environment.wind.speedApparent”,”value”: 2.423085},{“path”: “environment.wind.angleApparent”,”value”: 2.879794}]}]}Why is navigation.position different ? This complicates the object transformation using GSON…..
April 3, 2018 at 12:26 pm #875Hi Fred,
I think the difference between Position and other Signal K values, is that position had three fields; Latitude, Longitude and Altitude which are all under the same schema key, where as Course Over Ground, Speed Over Ground, etc. all have a single unique key and value.
In theory the Signal K developers could have separated the three fields in to three separate keys, but then you would need to have a way to link them, as you would not want a Latitude from one source to be mixed with the Longitude of another source. I had assumed that this was a normal way for positions to be stored in a JSON schema but your post did make me question this decision.
Do you belong to the Signal K Slack group? I would strongly recommend joining as you will then be able to chat directly to the core Signal K development team and gain from their knowledge and expertise…. http://slack-invite.signalk.org/
If you have any further questions please let me know.
Best regards
PAUL -
AuthorPosts
You must be logged in to reply to this topic.