Two government datasets, one land report, zero analysts

Producing a land report used to mean pulling cadastral records from one place, actual-price registry data from another, and assembling them by hand into something a client could read. It is a few hours of work that a person does the same way every time.

An app now does it. You search a parcel, it builds the candidate list, attaches comparables from the price registry, and compiles the report.

Two government datasets, one output. The demo takes forty seconds and it lands well.

The demo is not the project

Public data is not a database with an API and a support contract. It is a set of files published by institutions that owe you nothing, in formats chosen for their own reasons, changing on a schedule nobody announced.

What actually consumed the time:

• Reconciling two datasets that describe the same land differently. Cadastral records and the price registry do not always agree on what a parcel is, and neither is wrong. Something has to decide, consistently, every time.
• Deciding what a valid comparable is. This is the part people assume is a lookup. It is a judgement about proximity, recency and use — and if you get it wrong the report is confidently useless, which is worse than an empty one.
• What the report says when the data is thin. Some parcels have no recent comparable sales. The honest output is an explicit gap, not an estimate assembled from whatever was nearest.

That last one shaped the whole thing. A report that never admits missing data will be caught out eventually, and once a valuation tool has been caught out once, nobody in that office opens it again.

Automation moves the work, it does not remove it

Before the app, the human hours went into assembly. After it, they go into deciding what the tool should do when the data does not cooperate — which happens more than the demo suggests.

That is the honest version of the trade. You are not deleting the work. You are moving it upstream, from something repetitive to something that needs judgement, and doing it once instead of on every report. Whether that is worth it depends entirely on how many reports you produce.

At one report a month, it is not. At fifty, it obviously is. The interesting cases are in between, and the question to ask is not "can this be automated" — nearly everything can — but "how many times will we do this again."

What would not transfer

Taiwan publishes cadastral and actual-price-registry data in a usable form. That is a real advantage and it is not universal. Land data quality varies enormously by jurisdiction, and in places where the registry is incomplete or not machine-readable, this project is a data-acquisition problem wearing a software costume.

Before scoping anything like this, get the raw files and open them. Not the documentation — the files. The gap between what a dataset is described as and what it contains is where these projects go wrong, and it is a morning's work to find out.

*This work was delivered by Fish (余啟彰) within his own practice, before and alongside FDE Taiwan. It forms part of the team's combined track record rather than an FDE Taiwan client engagement.*

Public-data plumbing is unglamorous and it is most of the job. If that is the shape of your problem, it is what forward-deployed engineering is for — someone inside your team who does the reconciliation rather than describing it.