Đặc điểm & Thông số kỹ thuật dữ liệu đầu vào

Dữ liệu được trích xuất từ bộ thư mục bản đồ quốc gia tỷ lệ 1:1.000.000 phiên bản công chúng. Phạm vi bao phủ toàn bộ lãnh thổ lục địa cùng các quần đảo trọng yếu. Dữ liệu gốc được đóng gói dưới dạng File Geodatabase, phân mảnh thành 77 tấm bản đồ tuân thủ chuẩn GB/T 13989-2012. Đơn vị không gian mỗi tấm có kích thước cố định 6° kinh độ × 4° vĩ độ.

• Hệ quy chiếu: CGCS2000 (EPSG:4490 hoặc tương đương dự án).
• Độ cao: Quy chiếu VN-2000 / 1985.
• Cấu trúc thuộc tính: Phân loại thành 9 nhóm đối tượng chính, trong đó nhóm ranh giới hành chính (bao gồm quốc, tỉnh, huyện/phường) chứa các trường mã định danh duy nhất và tên vùng.
• Sai số không gian: Sai số trung phương vị trí mặt phẳng nằm trong khoảng ±50m đến ±200m tùy hạng đối tượng.

Mục tiêu xử lý

• Tổng hợp đồng nhất các lớp vector ranh giới hành chính xuyên suốt 77 tấm bản đồ, giải quyết tình trạng đường biên bị gián đoạn tại giao lộ tấm.
• Chuẩn hóa cấu trúc dữ liệu và hệ tọa độ về một hệ quy chiếu chung.
• Tối ưu hóa bộ nhớ và tốc độ truy vấn bằng cách đổ dữ liệu đã xử lý vào cơ sở dữ liệu PostgreSQL kèm extension PostGIS.

Kiến trúc dòng chảy xử lý (ETL Spatial)

Luồng xử lý được xây dựng trên ngôn ngữ Java, tận dụng thư viện GDAL/OGR để đọc ghi định dạng GDB. Cơ chế điều khiển áp dụng sự kết hợp giữa Pattern Strategy (chọn trình xử lý động) và Chain of Responsibility (nối tiếp các bước biến đổi).

Quy trình được chia thành ba giai đoạn chính:

1. Phase 1 - Normalization: Đồng bộ hệ tọa độ, gán CRS chuẩn, chuyển đổi kiểu hình học về dạng WKB/WKT nội bộ.
2. Phase 2 - Spatio-Temporal Merge: Áp dụng thao tác Dissolve không gian dựa trên cặp khóa thuộc tính (Mã hành chính + Tên vùng), tự động vá lỗi trùng lặp đỉnh và loại bỏ ranh giới trùng lắp.
3. Phase 3 - Dump/Export: Ghi trực tiếp vào bảng PostGIS hoặc xuất ra định dạng Shapefile/GeoJSON theo yêu cầu nghiệp vụ.

public class GeoProcessingPipeline {
    
    private final GeoConfigLayer config;
    private List<SpatialProcessor> processorChain = new ArrayList<>();

    public GeoProcessingPipeline(GeoConfigLayer cfg) {
        this.config = cfg;
        initializeChain();
    }

    // Cấu trúc định nghĩa lớp dữ liệu đầu vào
    public record GeoConfigLayer(
        String sourceDriver,      // Ví dụ: OpenFileGDB
        String targetCRSId,       // EPSG:4490
        String dissolveKeys,      // "PAC_CODE, REGION_NAME"
        String outputTablePrefix  // prefix_boua_1000000
    ) {}

    private void initializeChain() {
        // 1. Chuẩn hóa CRS
        processorChain.add(new CrsTransformer(config.targetCRSId()));
        // 2. Làm sạch hình học & vá lỗ hổng nhỏ
        processorChain.add(new GeometryValidator());
        // 3. Hợp nhất không gian theo khóa
        processorChain.add(new SpatialDissolver(config.dissolveKeys()));
        // 4. Đổ dữ liệu xuống DB
        processorChain.add(new PostGiSDumper(config.outputTablePrefix()));
    }

    public void execute(File tileDirectory) {
        var gridBounds = calculateTileGridBounds(tileDirectory);
        
        for (var tilePath : scanValidTiles(gridBounds)) {
            var ds = openVectorDataset(tilePath, config.sourceDriver());
            
            for (var processor : processorChain) {
                ds = processor.transform(ds, config);
            }
            flushToDatabase(ds);
        }
    }

    private GridBounds calculateTileGridBounds(File baseDir) {
        // Tính toán khung kinh-vĩ độ quét tự động dựa trên folder gốc
        return new GridBounds(72, 138, 43, 53);
    }
}

Cấu hình môi trường triển khai

• Hệ điều hành: Debian 12 / Fedora Workstation (Kernel hỗ trợ libgdalalljni).
• Ngôn ngữ: JDK 11 trở lên.
• Cơ sở dữ liệu: PostgreSQL 14 + PostGIS 3.3+
• Thư viện GIS: GDAL 3.5+ (cần dịch thủ công bindings Java nếu OS package không đi kèm).
• Cài đặt native library (Linux):

# Sao chép thư viện động sang đường dẫn JVM chấp nhận
sudo mkdir -p /usr/java/packages/lib
sudo ln -sf /usr/lib/jni/libgdalalljni.so /usr/java/packages/lib/libgdalalljni.so
# Đặt biến môi trường nếu cần
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni

Xử lý thách thức về khe hở hình học

Khi thực hiện hợp nhất các đa giác cạnh nhau từ file GDB gốc, thường xuất hiện các vết nứt (gaps) không mong muốn dọc theo đường biên. Nguyên nhân chính đến từ sai số làm tròn tọa độ khi thu thập dữ liệu vệ tinh hoặc sai lệch định vị giữa hai tấm bản đồ liền kề. Các khe hở này gây gián đoạn tính liên tục của đối tượng polygon.

Giải pháp kỹ thuật áp dụng tại bước tiền xử lý hình học:

• Thiết lập tham số tolerance (độ dày buffer âm/dương) nhỏ (~0.0001 độ) để ép các đỉnh kề sát lại gần nhau.
• Loại bỏ các đa giác rỗng (ST_IsValidRing) và đối tượng cắt chéo chính nó.
• Sử dụng hàm ST_ConcaveHull hoặc ST_Buffer(0) trên tập hợp vector sau khi dissolve để tự động lấp đầy các khoảng trống vi mô mà không làm biến dạng hình thái tổng thể.

Theo kiểm chứng thực tế, công cụ xử lý vector thương mại thường cho kết quả khớp viền mượt hơn so với các giải pháp open-source ở bước tự động vá lỗi, đòi hỏi developer phải tinh chỉnh ngưỡng tolerance thủ công hoặc tích hợp thêm module snapping topology.

Quy trình lọc & Kết quả thực thi

Giai đoạn tiền xử lý trước khi merge bao gồm việc loại bỏ các đối tượng không thuộc phạm vi quản lý hành chính:

1. Lọc biển & đại dương: Giữ lại duy nhất các đối tượng có thuộc tính mã vùng đất liền (PAC != '250100').
2. Lọc vùng lãnh thổ ngoài: Loại bỏ đối tượng có mã quốc gia/chính trị ngoài vùng quy định.
3. Chuẩn hóa: Chuyển tất cả geometry về cùng hệ trục OGC WGS84/Web Mercator tùy nhu cầu hiển thị.

Trong bước SpatialDissolver, hệ thống gom nhóm các polygon trùng mã hành chính và tên gọi, xóa biên trùng lặp và tạo ra một đối tượng multipart duy nhất cho mỗi đơn vị hành chính. Số lượng bản ghi đầu ra sau khi hoàn tất xử lý stabilize ở mức khoảng 2.900 feature, phản ánh chính xác số đơn vị hành chính cấp huyện/quận hiện hành. Bảng kết quả được tối ưu chỉ mục không gian (USINGgist(geom)) để hỗ trợ truy vấn nhanh trong các ứng dụng thời tiết real-time.