Closed Nielsien closed 3 days ago
Looking at the structure and trying to understand it. What would make sense to me would be to:
/src/entry/ais-message.json
/src/core/ais-message/xyz.json
allOf
include of /src/core/ais-message/base-message.json
which has the shared propertiesais_message_type
which is the string enum with the known typesais_message_type
property will fixate the enum to a single valueSo much like a measurement entry an AIS message entry can be added to the journal and the contents will further specify what type it is.
Thanks again! When I have time this week I'll finish the schemas
Found some time to finish this pr
Closing this PR due to age. Please re-open if needed
In this pull request I created a new entry for AIS messages and the first schema for such a message.
But before I want to add all the other message schema's I wanted to discuss the preferred way of handling such an entry. So this pull request does not need to merged yet, since I'll add more message schema's after this.
The way I did it in this pr is that an AIS message has a
AisMessageEntry
which is very similar to theDeviceMeasurementEntry
. In this case each entry has his message object which contains the required properties for each message with all the schemas in seperate objects.So another way to do this is to implement the AIS messages in the
device-measurement.json
, since these have almost the same construct apart from the value.Like so (in
device-measurement.json
):In this case the ais gets sent like a measurement from a device.
Another way to do it is use the
entry_type
setup where we have a entry for each AIS message type. So for exampleentry-ais-position-report.ts
where the entry_type decides which schema to use.