Polyline support

[mincequi]

Hi, i created a fork of this project to support polylines (a set of GPS coordinates). This is loosely inspired by googles polylines: https://developers.google.com/maps/documentation/utilities/polylinealgorithm

Unfortunately, there is no definition from IPSO for polylines, so I just went ahead and defined/wrote it myself.

So, my question is: are you willing to support data types that are NOT defined by IPSO and if yes, which number shall i assign this to (maybe start at 240? (as it is TBC from IPSO), or 151? (GSM types), or 187? (OpenAIS types)).

Short summery about my implementation (will create a PR for review): my impl can encode a set of GPS coordinates (e.g. a Route) very efficiently through delta compression. So, i encode a single GPS coordinate with 6 bytes (3 byte for lat/long each) and then pack the deltas for next coordinate in a single byte (4 bit for lat/long each). Another aspoect is, that my payload will have a dynamic size, so the first byte after channel and type is indicating the length of the polyline.

Please, tell me what you think :)

[sabas1080]

@xoseperez @wero1414

[sabas1080]

@mincequi we accept non-IPSO data, I only have doubt with the number that we should assign to this, I have tagged some contributors

[mincequi]

Ok, PR is open for review. Looking forward to your feedback.

[xoseperez]

I think it's OK to add new types. The library already has non-IPSO data. But I also think that at some point it will be good to have a way to add custom fields (don't know how) to include any non-standard fields to the buffer. Otherwise we will soon run out of codes for specific types.

[mincequi]

Hmm, before i came across this library, i spent some time using MessagePack. We could reuse their integer encoding to provide additional type infos for special values of type. https://github.com/msgpack/msgpack/blob/master/spec.md#int-format-family

e.g. encode Types 0-127 directly (ok, we already exceeded this limitation...) For type 0xCC there is another byte following allowing Types/Values 0-256. For type 0xCD there are another two bytes following allowing Types/Values 0-65536.

Another source of inspiration is the BIPSO spec (IPSO for Bluetooth Low Energy): https://github.com/bluetoother/bipso/wiki/BIPSO-Specification

They also have a flags field in their payload, to indicate optional parameters...

[mincequi]

I further optimized my impl with very good results. Some sample routes with 20km distance encode to 110-120 bytes with a precision of -/+ 25 meters.

Results for other precisons: 0.0001° -> 439 bytes (-/+ 5m) 0.0002° -> 238 bytes (-/+ 10m) 0.0005° -> 120 bytes (-/+ 25m) 0.001° -> 69 bytes (-/+ 50m) 0.002° -> 42 bytes 0.005° -> 20 bytes 0.01° -> 14 bytes 0.02° -> 12 bytes 0.05° -> 10 bytes

[sabas1080]

I think a source of inspiration can be BIPSO

[sabas1080]

I have accepted the changes in #32 , for Polyline support. At some point we will see about the custom fields