Bài 21 – Thông tin quy hoạch, kế hoạch sử dụng đất và hạn chế quyền được tích hợp ra sao? tiếp tục series Hệ thống thông tin BĐS V2. Bài tập trung vào cách tổ chức dữ liệu, nguồn, thời gian, quyền và kiến trúc tích hợp để thông tin có thể được sử dụng đáng tin trong quản lý và thị trường.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Bài viết phục vụ học tập và giảng dạy trong series Hệ thống thông tin BĐS V2. Nội dung pháp lý được đối chiếu theo văn bản hiện hành được nêu tại phần nguồn; khi áp dụng thực tế cần kiểm tra bản sửa đổi, văn bản hướng dẫn và phạm vi dữ liệu cụ thể. Các tình huống/số liệu minh họa được ghi rõ là giả lập.
Ranh giới với các series khác: Bài này trình bày kiến trúc và dữ liệu của HTTT đất đai. Phân tích điều kiện pháp lý cụ thể thuộc Pháp lý BĐS; thao tác GIS/API/CSDL chi tiết thuộc Tin học BĐS.
1. Quy hoạch là dữ liệu có ngữ nghĩa pháp lý và thời gian
Không nên coi lớp quy hoạch chỉ là một polygon có màu. Mỗi vùng cần loại quy hoạch/kế hoạch, cấp lập, thời kỳ, quyết định phê duyệt, ngày hiệu lực, trạng thái, mục tiêu/chỉ tiêu liên quan và liên kết nguồn. Khi có điều chỉnh, phiên bản cũ không nên bị ghi đè nếu hệ thống cần kiểm tra lịch sử.
2. Tách Spatial Plan khỏi hiện trạng sử dụng
Hiện trạng sử dụng đất mô tả trạng thái hiện tại; spatial plan mô tả định hướng/quy định có hiệu lực cho một thời kỳ. Trộn hai lớp sẽ làm người dùng hiểu sai 'đang là gì' với 'được định hướng/quy định thế nào'.
3. Hạn chế quyền là lớp quan hệ, không chỉ cờ cảnh báo
Một tài sản có thể bị ảnh hưởng bởi hành lang bảo vệ công trình, di sản, môi trường, an toàn, quy hoạch hoặc điều kiện xây dựng. Hệ thống cần loại hạn chế, nguồn, phạm vi, mức độ, thời hạn và đối tượng bị tác động.
| Đối tượng | Trường tối thiểu | Lưu ý |
|---|---|---|
| Spatial plan | plan_id, type, period, geometry | Có version |
| Approval source | document_no, date, authority | Liên kết nguồn |
| Restriction | type, scope, rule | Không chỉ yes/no |
| Impact link | parcel_id, overlap | Kết quả tính toán |
| Public view | legend, source, refresh | Giải thích ngữ cảnh |
4. Spatial overlay chỉ là bước phát hiện tác động
GIS có thể xác định thửa giao cắt vùng quy hoạch/hành lang, nhưng overlay hình học không tự kết luận quyền pháp lý. Kết quả phải được đối chiếu với văn bản, tỷ lệ bản đồ, độ chính xác và quy tắc nghiệp vụ.
5. Quản lý phiên bản quy hoạch
Khi quy hoạch được điều chỉnh, cần version_id, valid_from, valid_to, approval_source và geometry/version. Điều này cho phép trả lời: tại ngày ký giao dịch, lớp quy hoạch nào đang có hiệu lực?
6. Kế hoạch sử dụng đất và mốc thực hiện
Kế hoạch có thể có thời kỳ, danh mục dự án/khu vực và chỉ tiêu. Hệ thống không nên biến mọi đối tượng trong kế hoạch thành trạng thái 'đã thu hồi' hay 'đã triển khai'; cần trạng thái triển khai riêng.
7. Truy vấn tác động ở cấp tài sản
Người dùng cần biết một thửa/tài sản chịu lớp quy hoạch/hạn chế nào, phần diện tích giao cắt bao nhiêu, nguồn nào và hiệu lực khi nào. Đây là view tổng hợp từ nhiều domain chứ không nên sao chép thông tin vào bảng parcel.
8. Công khai thông tin và giải thích
Portal công khai cần đơn giản hóa nhưng không được làm mất ngữ cảnh. Màu sắc trên bản đồ nên đi kèm chú giải, nguồn, ngày cập nhật và cảnh báo về mục đích tham khảo/giá trị pháp lý theo quy định.
Khung kiến trúc: dữ liệu phải đi qua những lớp nào?
Ở hệ thống quản lý đất đai, một chỉ tiêu hoặc bản ghi đáng tin không xuất hiện trực tiếp từ giao diện. Nó đi qua chuỗi nguồn → tiếp nhận → chuẩn hóa → định danh → kiểm soát chất lượng → lưu trữ có lịch sử → semantic/service → người dùng. Nếu bỏ một lớp, rủi ro thường bị đẩy sang người dùng cuối.
| Lớp | Câu hỏi kiểm soát | Đầu ra |
|---|---|---|
| Source | Nguồn nào, quyền dùng gì? | Provenance |
| Ingestion | Batch/API/event? | Raw record |
| Standardization | Đơn vị/code/format? | Normalized data |
| Identity | Đối tượng nào? | Master/crosswalk |
| Quality | Có hợp lệ/trùng/hết hạn? | DQ flags |
| History | Phiên bản nào? | Temporal record |
| Semantic/service | Định nghĩa nghiệp vụ? | API/KPI/view |
| Consumption | Ai dùng để làm gì? | Decision/service |
Đặc biệt, lineage phải xuyên chuỗi: từ một KPI/thuộc tính hiển thị có thể truy về bản ghi nguồn và rule biến đổi. Điều này giúp giải thích sai lệch và tái tạo kết quả khi có kiểm tra.
Ma trận đánh giá nguồn và độ tin cậy
Không nên gắn nhãn nguồn “tốt/xấu” một cách tuyệt đối. Nguồn phù hợp phụ thuộc trường dữ liệu và mục đích. Một nguồn có authority cao nhưng cập nhật chậm; nguồn nền tảng nhanh nhưng thiên lệch. Hãy đánh giá theo field/use case.
| Tiêu chí | Câu hỏi | Ví dụ kiểm soát |
|---|---|---|
| Authority | Ai tạo/chịu trách nhiệm? | Cơ quan/hệ nguồn |
| Coverage | Bao phủ gì? | Địa bàn/phân khúc |
| Freshness | Mới đến đâu? | refresh_at/SLA |
| Granularity | Chi tiết mức nào? | parcel/unit/project |
| Bias | Thiên lệch gì? | listing bias/sample bias |
| Traceability | Có bằng chứng? | source_id/document |
| Permission | Được dùng/chia sẻ? | license/purpose |
Source score chỉ hỗ trợ quyết định; không được dùng một điểm tổng để che mất lỗi nghiêm trọng. Ví dụ dữ liệu không có quyền sử dụng thì freshness cao cũng không làm nó trở thành nguồn hợp lệ.
Tình huống giả lập phục vụ giảng dạy
Một thửa giao cắt 18% vùng hành lang, 100% khu quy hoạch nhưng lớp quy hoạch vừa có quyết định điều chỉnh. Hệ thống cũ chỉ hiển thị 'có quy hoạch'. Hãy thiết kế record nào cần version và cách giải thích cho người dùng.
Không được trả lời chỉ bằng 'lấy nguồn chính xác nhất'. Hãy xác định: đối tượng nào, loại dữ liệu gì, source authority theo field, thời gian hiệu lực, độ trễ, quyền dùng, rule hợp nhất và cách hiển thị uncertainty. Đây là cách phân biệt tư duy HTTT với việc gom dữ liệu vào Excel.
| Bước | Câu hỏi | Kết quả phải có |
|---|---|---|
| 1 | Đang hỏi dữ liệu/khái niệm nào? | Semantic definition |
| 2 | Nguồn nào tạo/khẳng định? | Source matrix |
| 3 | Thời điểm nào? | Valid/record time |
| 4 | Có mâu thuẫn/trùng? | Reconciliation rule |
| 5 | Ai quyết định exception? | Owner/steward |
| 6 | Người dùng thấy gì? | Value + source + confidence |
Khung áp dụng thực tế
- Thiết kế schema conceptual cho SpatialPlan + Restriction + Source.
- Mô hình một điều chỉnh quy hoạch có version.
- Tạo view tác động lên parcel mà không copy dữ liệu.
- Đề xuất public map có methodology.
Những sai lầm cần tránh
- Lưu quy hoạch như ảnh/PDF không có geometry và metadata.
- Dùng overlay để kết luận pháp lý tự động.
- Ghi đè quy hoạch cũ.
- Chỉ có cờ 'vướng quy hoạch'.
Phòng thí nghiệm dữ liệu: kiểm tra trước khi đưa lên dashboard hoặc dịch vụ
Hãy chọn một trường/chỉ số quan trọng và đi ngược lineage: người dùng nhìn thấy gì → định nghĩa ở semantic layer → rule biến đổi → curated record → raw source. Tại mỗi bước, ghi owner, timestamp và lỗi có thể xảy ra. Nếu không truy ngược được, chưa nên coi dữ liệu là 'nguồn sự thật'.
| Kiểm thử | Đạt khi | Không đạt khi |
|---|---|---|
| Identity | Một đối tượng map ổn định | Join bằng tên tự do |
| Semantics | Có data dictionary | Mỗi phòng hiểu khác |
| Time | Có effective/refresh | Không biết dữ liệu cũ |
| Provenance | Có source/evidence | Không truy nguồn |
| Quality | Có rule/exception | Lỗi chỉ phát hiện thủ công |
| Permission | Có purpose/access | Sao chép tự do |
Bài tập phản biện
Chọn một quyết định thực tế mà dữ liệu bài này hỗ trợ. Viết ba trường hợp hệ thống có thể đưa ra kết luận sai dù không có lỗi phần mềm: sai định nghĩa, sai thời điểm, sai nguồn hoặc sai phạm vi. Với mỗi trường hợp, đề xuất một guardrail ở tầng dữ liệu/quy trình thay vì chỉ cảnh báo người dùng.
Câu hỏi tự kiểm tra
- Khái niệm này có đang bị giản lược thành một field/cờ nhị phân quá mức không?
- Nguồn nào có thẩm quyền hoặc phù hợp nhất cho từng trường dữ liệu?
- Thông tin có hiệu lực ở thời điểm nào và có phiên bản không?
- Nếu hai nguồn mâu thuẫn, ai và theo rule nào xử lý?
- Người dùng có truy được source và methodology không?
- Dữ liệu này thuộc master, transaction, reference hay analytical layer?
Thiết kế truy vấn “tác động quy hoạch” đúng ngữ nghĩa
Một truy vấn tốt không chỉ trả true/false. Nó nên trả plan_id, restriction_type, phần diện tích/không gian bị tác động, mức chồng lấn, thời kỳ, quyết định phê duyệt, trạng thái hiệu lực và ngày dữ liệu được cập nhật. Người dùng có thể cần bản đồ minh họa, nhưng record pháp lý và source phải là đối tượng riêng. Nếu geometry được cập nhật mà quyết định nguồn không đổi, hệ thống vẫn phải biết đây là correction hay amendment.
Ở cấp dịch vụ, có thể tách spatial impact service – tính toán giao cắt – khỏi legal interpretation. Cách tách này giúp tái sử dụng GIS mà không biến thuật toán overlay thành 'phán quyết pháp lý'.
Ghi nhớ trong 30 giây
- Quy hoạch không chỉ là lớp bản đồ; phải có căn cứ, phiên bản, thời kỳ, trạng thái và nguồn.
- Không nên ghi 'vướng quy hoạch' như một cờ nhị phân nếu chưa xác định loại, phạm vi và hiệu lực.
- Hạn chế quyền có thể phát sinh từ nhiều nguồn: quy hoạch, hành lang bảo vệ, di sản, hạ tầng, môi trường.
- Spatial overlay giúp xác định đối tượng bị tác động nhưng quyết định pháp lý vẫn phải dựa trên quy định và hồ sơ nguồn.
- Quy hoạch cần được version hóa để truy lại trạng thái tại thời điểm giao dịch hoặc giải quyết hồ sơ.
Nguồn tham khảo
- Luật Đất đai 2024 – hệ thống thông tin và cơ sở dữ liệu đất đai; quy hoạch, kế hoạch sử dụng đất.
- Thông tư 09/2024/TT-BTNMT – nội dung, cấu trúc và kiểu thông tin CSDL quốc gia về đất đai.
- ISO 19152-5:2025 – LADM Part 5: Spatial plan information.
- Bài giảng Hệ thống thông tin BĐS 2026–2027 – nội dung LIS, GIS và minh bạch thông tin.
Bài tiếp theo: “Dữ liệu giá đất, định giá và nghĩa vụ tài chính nên kết nối với LIS thế nào?”.