sub id's for individual members of units

[danielsteiner]

I think IDs should have something like sub ids - for example, if one units ID is ID-2asdfasdfasdf, the members of the unit should be able to use the same unit but the geobroker should return a sub-number e.g. ID-2asdfasdfasdf#1 so that you can regiser devices as fallback and only use location data of unit ID-2asdfasdfasdf#2 when ID-2asdfasdfasdf#1 has not sent a location update in a certain time.

With this change, every member of a unit can install the app or open the website and there can't be any confusion with different location data from several devices.

[heinrichmartin]

I'd first check how bad it is to allow multiple devices per id in a real scenario.

But you captured my thinking ...
Concerning the design, this can already be implemented against existing geobroker and geoclient. Note that the geobroker holds the information which "unit" can see which other "units", but coceso manages it. Suggested logic:

• Create one id for the unit and one for every member.
  • Members of a unit shall carry the unit name along with name or role of the member. (but DSVGO!?)
  • All members shall share the target position with their unit.
  • The current position of the unit shall be updated with fallback data as you described.
  • Members of a unit shall not see the unit, but all members.
  • The unit shall not see itself, but all members.
  • Members and units shall not see other units' members, but the units (while they share an incident).
  • A property per unit shall define whether officers see the unit or its members.

It is an important design decision whether geobroker stays as simple as it is or whether it should implement business logic.

Pro my suggestion:

• value added: members can locate each other; officers can locate members on request
• keep geobroker simple

Con:

• extra effort for administration (but we already administer the members, don't we?)
• ghost members, if they do not register in the app (or create members only on request)
• more load on coceso (vital application!)

Mitigation: implement in geobroker, but extend the API

• set the number of members per unit
  • optionally set the display name (suffix) per member
• set whether a unit is an officer
• set per unit whether officers see the unit or their members

All the above to be reviewed ...

[robo-w]

I think the geobroker shall stay as tracking tool per unit. As I understand the main request here, it is about having multiple devices registered, and using the most reliable source.

This can be done by adding the device-id to the position request. Then the geobroker can define by internal rules, which sources is used for the position provided to other parties:

• Stick to the first one sending
• Keep the position source, as long as it sends continously. Switch over to the next one, if no further updates are received for n minutes (avoid flickering)
• Switch to a different source, if another source provides a better accuracy

[heinrichmartin]

Looks like a decision, but still with a few questions:

• keep the private API, i.e. a unit stays a unit only
• distinguish multiple senders of position data
  • don't use # as a separator in URL parameters, think of / or .
  • allow arbitrary suffices (e.g. random ones), geobroker handles them as strings
  • senders can join and leave as they like, i.e. no registration required, share the token!
• the geobroker implements some heuristic to chose the position data
  • prevent flickering
  • all senders are equal
  • no maths, i.e. no mean of all senders

How will we generate QR-codes?

[danielsteiner]

What about appending a second get parameter like device={devicetoken} via JavaScript in the webclient or in the app by reading the device id (http://codeworks.it/blog/?p=260) and then do the management in geobroker

[heinrichmartin]

Any UUID or random value would do. I like `device={anything}`, no need to generate more QR codes...