Environment.water Sub-Group is a bit inconsistent

[sumps]

Just adding some missing descriptions and noticed that the Environment.water sub-group is inconsistent as it has environment.water.temperature which is the temperature of the water mass that the vessel is sailing in, environment.water.salinity which is the the salinity of the water mass that the vessel is sailing in (so far so good) and then it tags on environment.water.liveWell and environment.water.baitWell at the end which is water but completely different water in a completely different location.

I think these two should be locations in their own right, like outside, inside and perhaps water should become waterMass or seawater, even though sometimes it may be lakewater or riverwater, but I think seawater is OK as a generic term for the water the boat is floating in.

If we are going to have environment sub-groups based on location we have to be consistent.

[sumps]

Alternatively we could place the baitWell and liveWell as part of the environment.inside subgroup like a freezer as they may not be inside the hull but the wells are enclosed and not outside.

Following this logic, the seawater temperature could be environment.outside.water.temperature and environment.outside.water.salinity so we end up with just two locations inside and outside.

[timmathews]

+1 for renaming water to seawater. Its a well-known term and I doubt any freshwater mariners would object in this context.

And I agree, there is definitely some inconsistency in environment. It was one of the first groups defined and we were still sort of feeling our way about. And there have been a lot of changes to this section see: #170, #186, #214, #216, #217.

outside was intended to contain environmental data about your immediate surroundings (excluding the water you're floating in). In fact, it used to be called air. Essentially, the sort of data that you might get from a weather station. When viewed in that light, the data that is contained in outside makes perfect sense. Of course in retrospect, water temperature and salinity should probably be contained in outside. Hopefully your seawater is always on the outside.

inside on the other hand doesn't really follow any rules. It's mostly temperatures (some very specific) and one generic humidity. Viewed that way, liveWell and baitWell belong in inside a lot more than they belong in water.

That said, liveWell and baitWell have more in common with tanks than environmental data. They should probably live under tanks and not in environment at all. That way we could also monitor their levels, which seems important.

Here's a handy cross reference between NMEA defined temperature sources and Signal K paths

NMEA Temperature Source	Current Signal K Path
00: Sea water	environment.water.temperature
01: Outside air	environment.outside.temperature
02: Inside air	environment.inside.temperature
03: Engine room	environment.inside.engineRoom
04: Main cabin	environment.inside.mainCabin
05: Live well	environment.water.liveWell
06: Bait well	environment.water.baitWell
07: Refrigeration	environment.inside.refrigerator
08: Heating system	environment.inside.heating
09: Dew point	environment.outside.dewPointTemperature
10: Wind chill (apparent)	environment.outside.apparentWindChillTemperature
11: Wind chill (theoretical)	environment.outside.theoreticalWindChillTemperature
12: Heat index	environment.outside.heatIndexTemperature
13: Freezer	environment.inside.freezer
14: Exhaust gas	propulsion.\<instance>.exhaustTemperature

As you can see, there is some inconsistency in the nomenclature on the SK side. All of the key names should follow the format \<source>Temperature\<modifier>.

Here are some proposed changes:

NMEA Temperature Source	Unified Signal K Path
00: Sea water	environment.outside.seaWaterTemperature
01: Outside air	environment.outside.airTemperature
02: Inside air	environment.inside.airTemperature
03: Engine room	environment.inside.engineRoomTemperature
04: Main cabin	environment.inside.mainCabinTemperature
05: Live well	tanks.liveWell.temperature
06: Bait well	tanks.baitWell.temperature
07: Refrigeration	environment.inside.refrigeratorTemperature
08: Heating system	environment.inside.heatingTemperature
09: Dew point	environment.outside.dewPointTemperature
10: Wind chill (apparent)	environment.outside.windChillTemperatureApparent
11: Wind chill (theoretical)	environment.outside.windChillTemperatureTheoretical
12: Heat index	environment.outside.heatIndexTemperature
13: Freezer	environment.inside.freezerTemperature
14: Exhaust gas	propulsion.\<instance>.exhaustTemperature

And all of the generic, user-defined n2k temperature sources (source ID 129 through 252) should be filed under the generic environment.temperature.<sourceID>, which we should add to the schema.

[sumps]

YES - makes perfect sense to move the live and bait wells to tanks, good proposal.

I am happy with all of the above.

[pod909]

Outside is a context Air.temperature is an attribute Environment is an attribute grouping Tanks and live well are contexts

Should be more like

Outside.environment.air.temperature Outside.environment.water.temperature Outside.environment.air.windchillApparents Inside.freezer.environment.air.temperature Tanks.baitwell.environment.water.temperature

Or if the attribute group must come first Environment.tanks.baitwell.water.temperature Etc

[pod909]

There are some common things about the liquid in a tank and the sea and tide that we want to know about. So I was wondering if they might be modeled in a consistent manner.

First off the idea of moving livewell to tanks is on the money. Taking the current keys we're going to end up with: environment.outside tanks.livewell.xxxx tanks.freshwater.xxxx etc. As the context for these attributes.

I think seawater is perhaps a little to prescriptive. We could get away with just "sea". So how about: environment.outside.sea and tanks.livewell.tankX.water

For environment.outside.sea and tanks.freshwater.tank01 we're interested in "level" of the fluid and the following properties of that level: latest/value min max absMin absMax datum

Sea.level is a slightly more generic label than "tide" but none the less its a well understood term in a nautical context.

And we're interested in "salinity" and "temperature".

We might also be interested in: latest/value min max

For the remaining temperatures there talking about air environment.outside.air environment.inside.enginroom ... or perhaps environment.inside.room.engine.air environment.inside.room.main.air environment.inside.refrigerator.air environment.inside.freezer.air propulsion.xxxxxx.exhaust

In each case we're interested in the temperature, and the following properties of the temperature .latest/value .min .max .dewPoint .windChillApparent .windChillTheoratical .headIndex

Suggested keys as a result:

01 Sea Water environment.outside.sea.temperature.value

01 Outside Air 09 Dew point 10/11. Wind chill (apparent/theoretical) environment.outside.air.temperature.value|windChillApparent|windChillTheoretical|dewPoint

2. Inside air environment.inside.air.temperature.value

03: Engine room environment.inside.room.engine.air.temperature.value

04: Main cabin environment.inside.room.main.air.temperature.value

05: Live well tanks.livewell..water.temperature.value

06: Bait well tanks.baitwell..water.temperature.value

07: Refrigeration environment.inside.refrigerator.air.temperature.value

08: Heating system environment.inside.heating.air.temperature.value

12: Heat index environment.outside.air.temperature.heatIndex

13: Freezer environment.inside.freezer.air.temperature

14: Exhaust gas propulsion..exhaust.temperature

Generic user defined temperatures would be exactly what the discussion in RFC00001 and 6 look to address.

These suggestions are not backwards compatible but nore is the original suggestion. Nore has the community been against radical change in the past.

Is this just a "tidy up"? To me it's not. It's necessary work required to put SK on a good footing for further expansion and not just the minimum required to give NMEA2000 values a slightly different label (often a might to close to NMEA IP in terms of name and structure for my taste BTW) and adding them to what increasingly amounts to a single list.

Compromises where forced on the NMEA experts by the inherent nature of CAN. Why we're living with them here I'm not too sure.

[bkp7]

I think this really needs resolving for v1. Presently it seems we can only add in temperature information for things which NMEA2000 envisaged. ie we've not achieved anything extra.

For my money tanks and zones (rooms, spaces, areas or whatever you want to call them) are quite different. In tanks we are trying to contain a fluid and we want to know how much we have of it, what condition it is in, etc. Whereas areas that area open to the environment need different parameters.

For me the details we want to know about tanks are 'type' (water, petrol, etc), 'capacity', 'currentLevel', 'currentVolume' all of which we already have, but also: 'pressure', 'viscosity' and 'contaminants', others?

The bigger issue with tanks at the moment is that they are grouped by type with a list suggested by the scema (freshWater, wasteWater, baitWell, etc). The schema allows additional types but then doesn't enforce the rest of the structure onto new types. Ones which spring to mind are: extinguishant, gas, washerFluid....

'inside' also has a limited list of zones ('engineRoom', 'mainCabin', 'refridgerator', 'freezer' and 'heating') which all have well defined measurements (currently only temperature), but when additional zones are added the structure is no longer required. I can think of loads of zones that it would be useful to have: foreCabin, aftCabin, engineRoomPort, machineryRoom, fwdWatertightCompartment, fridge2, electricalCupboard, inverterCupboard, gasLocker, ropeLocker, galley, upperHelm, ......

In zones the details we want to know should include temperature, pressure, density, humidity, dewPoint, contaninants, bilgeWaterLevel, illuminance, movement, proximity, hvacDemand(thermostat), lightingLevel (on/off/dimmed), bilgePump(on/off), others?

For me the semantics of the structure aren't as important as having a structure. If we could agree to additional measurements as detailed above for tanks and zones, along with explicitly allowing user defined zones that would do the job. I would consider getting rid of the tank groupings so you just had user defined tank names at the top level, the same as for 'zones'. But perhaps that bird has flown?

Either way, this would formalise a whole load of additional functionality and can be done without breaking anything that is already there.

BTW the contaminants I have in mind are: water, CO, CO2, smoke, butane, propane, glycol, oil, others??