Two-decimal coordinates snap the heatmap 1.1 km off grid

• 116.397428, 39.909230 is stored and read back as 116.40, 39.91.
• Two to three hundred points in one business district collapse into a single grid cell and the heatmap shows square blobs.
• The whole layer sits about 1.1 km away from the road network; the worst rounding error is half a step, 0.55 km.

1. Run SHOW CREATE TABLE or \d+ poi and read the actual column type of lon and lat.
2. Write one known point and read it back; a difference that is a multiple of 0.005 means precision truncation.
3. Compare COUNT(DISTINCT lon, lat) with the row count; a much smaller distinct count proves mass quantisation.
4. Check whether the ORM maps a double to numeric(9,2) on the way in.
5. Confirm whether the original source still holds the untruncated values before planning a re-import.

Store coordinates as DOUBLE or DECIMAL(10,7), or double precision plus geometry(Point,4326) in PostGIS; after altering the column, re-import from the original source because truncated digits cannot be recovered.

-- 量化痕迹：不同坐标数远少于总点数
SELECT COUNT(*) AS total, COUNT(DISTINCT lon, lat) AS distinct_pts
FROM poi;
-- total 12840 | distinct_pts 913   -> 大量点被压到同一格

-- MySQL 8.0
ALTER TABLE poi
  MODIFY lon DECIMAL(10,7) NOT NULL,
  MODIFY lat DECIMAL(10,7) NOT NULL;

-- PostgreSQL + PostGIS：直接存几何，精度由 double 保证
ALTER TABLE poi ADD COLUMN geom geometry(Point, 4326);
UPDATE poi SET geom = ST_SetSRID(ST_MakePoint(lon, lat), 4326);
CREATE INDEX poi_geom_idx ON poi USING GIST (geom);

-- 新表建议
CREATE TABLE poi (
  id     bigserial PRIMARY KEY,
  name   text,
  lon    double precision NOT NULL CHECK (lon BETWEEN -180 AND 180),
  lat    double precision NOT NULL CHECK (lat BETWEEN -90 AND 90)
);

• Widening the column and expecting the existing rows to regain precision; the lost digits are gone.
• Keeping decimal(9,2) 'because it saves space', which is only acceptable for province-level schematic maps.