rob42
commented
5 years ago Re Location: You can use one of 3 options to 'locate' a note:
"region": {
"type": "string",
"description": "Region related to note. A pointer to a region UUID. Alternative to position or geohash"
},
"position": {
"description": "Position related to note. Alternative to region or geohash",
"$ref": "../definitions.json#/definitions/position"
},
"geohash": {
"description": "Position related to note. Alternative to region or position",
"$ref": "../definitions.json#/definitions/geohash"
},A position is a specific lat/lon, and as you say, a few decimals and its a different entry. This is where a geohash is useful. See https://en.wikipedia.org/wiki/Geohash. Basically the geohash is a single string that identifies a rectangle, the more chars the smaller area. So a search for less chars is like a zoom-out.
Another option is region which is a geojson polygon, and hence can outline any shape. By tagging notes with a region you can show all notes in the polygon. Downside is you have to define a region which can be laborious depending on the detail.
Both options could be auto-populated by your backend based in a position geohash or a lat/lon being within a region.
irandrews
tkurki
panaaj
We have a cloud database of around 15,000 'notes' (growing by 3,500 a year). Our 6,000 members share these notes in real time using an existing App and Website. We would like to (actually have done!) make these notes available via SignalK so that the range of clients can be expanded.
We can get the system to work (see the demo) but the current notes schema has a couple of limitations for us, and, I suspect, others. Specifically:
Location. Typically our notes are about Harbours and Anchorages. The first person to make a note about somewhere picks an arbitrary GPS point somewhere in the harbour and creates a note. Other users can add their own views to this location and these are all displayed on the screen at the same time. The current schema has no way to relate notes to each other - and specifically for the client to tell the server whether the note is about an existing location, or a new one. Unfortunately the 'name' field (which we use as the port name) is not unique, and the 'position' field only has to have a minor resolution difference for it to become a new location. Currently we are overloading the uuid field to provide this info, but this is against the schema. One solution might be for each note to have a pointer (like it does for 'region') to a named 'location' - aka a Waypoint - but we don't want to overload Waypoints as these can be used for different purposes and appear differently (i.e. in a different colour) on a screen. One possibility would be to create a new class of entity: 'location' (which has a GPS reference) or another would be to add a 'type' tag to the Waypoint entity so the client could determine what it relates to. I wouldn't want to remove 'position' from the note though.
Privileges. In our world users can edit/delete their own notes, but not one created by someone else. The current schema has no way for the server to tell the client what is editable and what is not, so that the client can put the relevant buttons on the screen. I favour something like a 'readonly' tag added to the note schema.