これまでのあらすじ

これまでの経緯は下記にあります。
https://qiita.com/R_28/items/54236fe1a78dd77872f5

原因

データベースに格納されている座標系の問題だった可能性が高い。
試しにジオメトリをSRID3857（球面メルカトル座標系）に変換せず、SRID4612（地理座標系）のままのデータベースを作成して
ベクタータイル化を試みた

SRIDについて
https://qiita.com/yellow_73/items/b98d3d1ef3abf7299aba

sample.sql


SELECT ST_AsMVT(q, 'rdcl', 4096, 'geom') 
FROM (
	SELECT
    	rdctg AS c1,
    	ST_AsMVTGeom(
            ST_LineMerge(ST_Collect(geom)),
            st_makeenvelope(tile2lon(58306,16), tile2lat(25693,16), tile2lon(58307,16), tile2lat(25694,16), 4326) ,
            4096,
            0,
            true) AS geom
    from (
        SELECT rdctg,(ST_Dump(geom)).geom from rdcl WHERE geom && st_makeenvelope(tile2lon(58306,16), tile2lat(25693,16), tile2lon(58307,16), tile2lat(25694,16), 4326) 
    ) a GROUP BY a.rdctg
) as q

便宜上、今回はST_Simplifyを行っていない。
メルカトル座標と緯度経度だと閾値の単位が異なり、比較しにくいので省略。
tile2lonとtile2latについては下記を参照
https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#PostgreSQL

赤：simple-vectorizerで作成したジオメトリ
黒：ST_AsMVTで作成したジオメトリ

ぴったり。

まとめ

ST_AsMVT、ST_AsMVTGeomについては地理空間座標系のジオメトリを使用する必要がありそう。

地理空間のジオデータベースの場合メルカトルに変換しなくてよいので、データベース運用についても見直せそう。

※関数仕様とかに記載がないか探してみましたが、見つからなかったので、見つけたら載せます。