Considering binary format output?

[ThomasG77]

Contrary to most REST API, the response size in web mapping can be really large due to complex geometry data.

Most of the time, the trick is about restricting number of returned features with attributes filtering, geometry filtering or a limit.

Unfortunately, for a complex geometry, it's not always enough.

Providing an output based on Protocol buffers or MessagePack could lower waiting time.

An existing implementation example for geospatial could be https://github.com/mapbox/geobuf based on 'Protocol buffer'.

[cholmes]

I'd definitely be +1 for binary output formats, but I don't think it should be in the core. Ideally there'd be small OGC standards for message pack and protobuf representations of 'simple features', and a WFS could choose to support them.

Hopefully the core is flexible enough already to supply alternate output formats, so you could pretty easily make a WFS that outputs geobuf. And/or mapbox would contribute the interface of geobuf

[ogcscotts]

Interesting idea - we have interest from at least one member to introduce a protobuf-focused standard for transmittal of 3D data.

[cportele]

Yes, we briefly discussed protocol buffers as a candidate for an encoding, but felt that it should not be in the core, as Chris said. It would be straightforward to add a conformance class for a binary encoding in another part, if there is interest.

However, the specification does not mandate any encoding. I.e., an implementation may also choose to not support GeoJSON or GML and only support an encoding based on protocol buffers.

The "Core" does not mandate any encoding or format for representing features or feature collections.

[cportele]

Discussed during the meeting on 2017-11-28:

Do not add a conformance class right now. A conformance class for a binary encoding could be added, if we see WFS implementations using such an encoding.