こちらのツイートに関連して、最近は GeoJSON Feature の NDJSON もやめて、シンプルに RFC 8142 をワイヤフォーマットとして使おうとしている理由を紹介します。

ここで、ワイヤフォーマットという言葉は、プロセス間のパイプを通すときのシリアライゼーションフォーマットという程度の意味で使っています。

RFC 8142 を使う理由

Node で RFC 8142 を書き出せる方法を暗記できた

RFC 8142 を書き出す場合は、record separator (RS) を最初に出す必要があります。

Node では、これは文字列の最初に \x1e と書けば OK です。 output ストリームに RFC 8142 で一地物 f を書き出すためには、このように書けば良いです。

output.write(`\x1e${JSON.stringify(f)}\n`)

OpenStreetMap には、改行を含むプロパティがあります。例えば、お店 POI の開店時間・閉店時間が詳しく書かれているような場合に、そのテキストに改行が含まれていることがあります。とりわけ、中央ヨーロッパにそのようなデータがあるようです。

NDJSON だと、このようなデータをエレガントに処理することは簡単ではありませんでした。RFC 8142 だと、GeoJSON Feature の中に改行が入っていても、そのままの形でシリアライズすることができます。

Tippecanoe と Osmium Tool は、 RFC 8142 に対応しています。

とりわけ、osmium exportが RFC 8142 に明示的に対応していることが、私が RFC 8142 を常用してみようか、と思ったきっかけでした。

Tippecanoe はどちらかというと NDJSON を使うのが一番素直な感じですが、RFC 8142 も区別なく扱ってくれる感じです。

あなたの舞台がウェブを含むインターネットであれば、それがジオであろうがウェブであろうが、IETF は最強の標準化集団であると主張できるでしょう。

これは、多分 RFC 8142 固有の問題ではないかもしれませんが、座標をテキストで扱うということから、RFC 8142 では出やすい問題かもしれません。

非常に巨大・複雑なポリゴンをパイプに通そうとするプログラムを書いた時に、 ENOBUF という私にとっては珍しいエラーが出たことがありました。

これは、多分パイプのために用意しているバッファを、RFC 8142 の一レコードが使い切ったことで出たのだと思います。

RFC 8142 はワイヤフォーマットとして使うのが適切だと思っていますが、現実には上述のような理由で、ディスクに一旦置かなければならないときがあります。その場合には、拡張子に迷うことになります。

私は .rfc8142 という拡張子を使っています