[Interop-dev] NetJSON + geographic coordinates

[Henning Rogge]

On Thu, Jun 14, 2018 at 3:37 PM Gabriel <(spam-protected)> wrote:
>
> Il 2018-06-14 11:36 Henning Rogge ha scritto:
> > Maybe we should also talk about what kind of data we would like to
> > transmit...
> >
> > minimum would be latitude/longitude...
> Are we ok with WGS84? I think we should abstract the lat/lon to generic
> X/Y/Z and add a field for the reference system.
> Sometimes is useful to have differente coordinate systems, for example
> for an indoor map.

if we go x/y/z we should make the "coordinate system" key/value pair
mandatory and have at least one based on angels and one based on
distance.

"spherical/linear" ?

"spherical"  -180=C2=B0<=3Dx<180=C2=B0, -90=C2=B0<=3Dy<=3D90=C2=B0, z =3D d=
istance in meters...
relative to what? "sea level" ?
"linear" just all three values in meters?

> > optional might include:
> > - height
> see above
> > - direction/speed (or movement in x/y/z?)
> > (direction can be meaningful even with speed zero)
> > - timestamp (when was the position taken, important for moving nodes)
> > - accuracy?
> > - source (configured, GPS, cellphone tower?)

> I'd also add the bearning and the elevation of the antenna, but in order
> to do this we should find a way to represent different antennas in the
> netjson.

This sounds more like the definition of "sub-objects"... sometime like
"antenna 1" has relative position/bearing compared to the main object.
Maybe an "antenna" subobject should have an ID that can be referred
from other netjson objects talking about the interface using the
antenna. Maybe allow having an object in NetJSON have a relative
coordinate to another NetJSON object (instead an absolute one)?

> Moreover for all these fields we should define the unit of measurements.
> For example: angles can be expressed in degree, radians or gradians.

As long as we stay away from "arcminutes/arcseconds" and just go for
degree and fractional degrees. I would suggest NOT allowing multiple
measurement units for angles or length/speed. Just stick with the
default one.

degree for angles, meters for distance, meters/second for movement.

Having multiple degrees of freedom for the same field will just make
all parsers more complicated.

Henning