Replies: 3 comments 8 replies
-
|
I feel there are a number of parts to this discussion:
At this time I'm going to ignore 1 & 2 and assume that they are addressed and focus my comments on how clients of various types will access / fetch the provided data. Operation & Signal K Paths and ValuesFrom the description provided it appears that the only output of the plugin is information regarding "features" that are "nearby" the vessel and this information is placed under To align with Signal K convention may I suggest the following:
This would result in the following being returned to the request {
"sectors": {
"uuid1": { // sector GeoJSON
},
...
},
"marinas": {
"uuid2": { // marina GeoJSON
},
...
},
"locks": {
"uuid3": { // lock GeoJSON
},
...
},
}Querying dataIt might also be advantageous if a client could query for features within a defined area rather than just those nearby.
Absence of EntriesThe convention in Signal K when there are no matching resources in a list is an empty set Example: {
"sectors": {}, // no sectors
"marinas": {
"uuid1": { ... },
"uuid2": { ... },
...
},
"locks": {}, // no locks
}Delta messagesAs it currently reads a client must use the REST API to retrieve information. Feature data formatI think there should be a distinction here around the format of the data:
While the plugin's data source will likely require a specific data format to perform the relevant operations and that there may be some overlap with the data that is presented to the client, they should be considered as separate schemas. For example, v2 Signal K resource schemas align to the following convention: {
"name": "feature name",
"description": "feature description text",
"attr_1": "attr1_value",
...
"feature": {
// GeoJSON feature
}Additionally the type is implied by the path So your example for a marina: {
'channel': integer, // VHF channel
'name': string, // Call name
'type': 'marina',
'mode': [announce|listen], // Indicate listen only, or actively report
}would look more like the following (type= 'marina' is implied by the path to the entry {
"name": "marina_name",
"channel": 40,
"mode": "announce"
"feature": {
"type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [ [[125.6, 10.1],[125.62, 10.1],[125.62, 10.15],[125.6, 10.15],[125.6, 10.1]] ]
},
"properties": { ... }
}
} |
Beta Was this translation helpful? Give feedback.
-
The uuid does not need to be the same across all installs but, if say a lock has an id (like an mmsi) that is unique that would be more than suitable as the UUID. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I completely understand this use case. |
Beta Was this translation helpful? Give feedback.
-
I know that here in The Netherlands there's VTS Brandaris which requires any chartership and ferry (regardless of size) to report when entering the sector and report destination port and number of people on board. Another is this example from @tkurki below based on vessel size. So the question is: how to store different rules in vhfData so that SignalK can pick up the right one based on vessel properties. From the pdf:
|
Beta Was this translation helpful? Give feedback.
-
|
I think that for this scenario the sector GeoJSON properties is the right place. |
Beta Was this translation helpful? Give feedback.
-
|
Nested properties are possible according to the RFC: So it in case certain info is boolean, it could be done like this: The plugin would in case of an object do the comparison. |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about the SK resources data structures and especially future APIs, using the VHF plugin as a guinea pig. Without getting bogged down by implementation details yet.. What I imagine Hans's UI would want to periodically is query the server for "all the resources that have vhf information that are relevant now". Relevant now meaning resources that are in the vicinity of my ship: position + radius. Then the plugin can perform more detailed logic, like figuring out where we're headed and show the vhf data data for resources in that direction. When planning a trip a UI like Freeboard could show all locks on the map, so it might want to query the server for all locks in the current map bbox. Or if I am thinking about what kind of vhf activity to expect query all resources that have vhf data in the map bbox. This sounds like we'd need to agree on how to represent and query for
To be honest I am not at all happy with adding qualified paths like I'd like the term UUID to refer only to https://en.wikipedia.org/wiki/Universally_unique_identifier - if there's an existing id system for some resource type, like locks, we can support that, but uuid is just an opaque id. In the context of the VHF plugin the plugin master db/repository could assign persistent uuids so they would not change over time. About modes: I was thinking it was more for rendering something to a human in the UI, not taking action on. Do we need |
Beta Was this translation helpful? Give feedback.
-
In line with your looking forward to future APIs, maybe the first question to answer here is "what is the resource?" in this context.
Then if the VHF information just becomes a class of attributes attached to a resource "should these attributes be applied to any resource type?" This approach will provide some flexibility but could ultimately create some unecessary complexity if taken too far, either way it starts to build a picture of what a resource is in the context of Signal K and "how do I work with it?". Questions like "can a lock be a waypoint along a route?" or "can a marina be set as a destination?" will most certainly be asked and the asnwers to these (and others) will certainly influence the development of clients like Freeboard. This use case provides a great test for the various approaches. |
Beta Was this translation helpful? Give feedback.
-
VHF data often has a 1:1 relation to a VHF lock/sector, but also 1:n here in Holland. The same VHFid could be stored in an existing Marina resource Geo point object as well as a Geo feature object. For my user display use case I'd:
That still leaves the question on how to store VHFdata in a logical way to allow filtering for different boat types. |
Beta Was this translation helpful? Give feedback.
-
GeoJSON propertiesCurrent idea is to make the properties part of the json look like this. Keeping the geo info and vhf data together allows to land the data in SignalK in multiple/different ways. vhfdata would contain vhf specific info per group and/or per ais type number. That seems specific enough for a most use cases. The possible types/numbers should be clarified using a table like this. I don't want to set a default type in the data and leave that to the plugin/client so it can (let the user) choose how to deal with different vhfdata entries for a geo resource. E.g. select own AIS ship type first, if fails then group, then tanker or decide to show multiple entries. Also these types don't have to be unique, as there can be multiple VHF channels active in a VTS area. For example Rotterdam harbour VTS which has 3 channels active. The data would be kept in a file per country using ISO 3166-1 alpha-2. Adding new geo featuresIt's not as user friendly as a purpose specific webpage, but can be done without Git knowledge.
PluginThe plugin would read the country files (or later the one for current position) and be able to do on or more of the following tasks:
|
Beta Was this translation helpful? Give feedback.
-
VHF mapping plugin
This post is to describe a plugin which ideally populates /resources/ for easy data pickup by others. The main ask is feedback on where to land the data in /resources and the format. E.g. how to treat different info for different vessels like different instructions on listen/report for vessels <24m vs >24m.
Intentions
While sailing you'll be required to either listen out or actively report on different VHF channels belonging to different types stations. This plugin's intention is to provide the VHF information based on geo coordinates and direction.
Why direction you may ask? Think about then you're approaching or leaving a lock. On approach you want to know about the lock's VHF, while when you're exit the lock, you want to know what's ahead and are no longer interested in the lock.
This will allow you to use this information to display in your cockpit like:
Format
The format to store the information is the feature GeoJSON. The format typically is:
This allows to store polygons together with properties.
Example
An example of some features in The Netherlands with properties can be seen here.
Plugin workings
Intersecting features would be reported based on distance, including information on bearing.
A negative distance means you're inside a feature.
That way the client can choose how many to show.
This shows a boat (pin) in a lock, facing West and 'seeing' the next sector and a marina:
The plugin uses turf.js to do the magic, which can easily create output like this:
OpenAPI v2
Provide geo features upon request by Signalk's subsytem.
Rest API
Direct API by the plugin providing geo features upon request.
/resources/
The plugin uses
navigation.positionto actively propogate:Creating a Feature
GeoJSON featuresare easily created using the GeoJSON.io website. The resulting GeoJSON can be easily copied and added to the plugin data files.
Data management
For now it's one big file. Once it gets to a point it needs to split up, we'll see what makes sense. Options are for instance:
Features
This is a list of features with their mandatory and optional properties.
Lock
When
While approaching and inside a lock.
Type
Polygon to know when you're in a lock and when you've left.
Details
Optional:
VTS sector
When
While approaching and inside a sector.
Type
Polygon obviously.
Details
Optional:
Military sector
When
While approaching and inside a sector.
Type
Polygon obviously.
Details
Optional:
Marina
When
While approaching and inside a marina.
Type
Polygon to know when you're in a marina and when you've left.
Details
Optional:
Beta Was this translation helpful? Give feedback.
All reactions