Considering streaming output

[ThomasG77]

Like the previous issue I opened #14, I would like to be able to use streaming output like http://ndjson.org
Why? it's about partial consumption of data and lowering footprint on the back-end as not streaming = output size = 600Mo and RAM consumption on the server = 600Mo

[cportele]

I would expect that most implementations will support "streaming", i.e. return features in a feature collection in chunks (e.g. feature by feature). Currently that is not discussed, but I agree that we should say something about it.

And we should mention that there is a standard for streaming GeoJSON: GeoJSON Text Sequences. This is similar to ndjson, but uses a different separator convention. I have not seen it used a lot, so we should first have more implementation experience before considering a conformance class.

[jdesboeufs]

It's mostly an implementation concern (from database to final client).
Many formats are streaming friendly: GeoJSON, Geobuf, CSV, GML…

In JS world we have:
https://github.com/dominictarr/JSONStream
https://github.com/node-geojson/geojson-stream (built upon JSONStream)

ndjson is interesting when you have to deal with line-by-line parsing (bash/grep, Python stdlib), but it is not very used.

[cportele]

Discussed during the meeting on 2017-11-28: The media type (and compression options etc) will determine the way the response is returned. The HTTP mechanisms can be used. Add a statement in the document, but no normative statement seems required.