a table cannot show you where the land is - landmap

My sibling kept a spreadsheet

My older sibling manages land property in Bali. Not professionally, just as part of the family, keeping track of plots that different relatives own, who bought what, how big each piece is, and roughly what it is worth.

For years they did this in a spreadsheet. When something changed, they updated a row. When someone asked about a plot near a certain area, they scrolled. When they wanted to compare values in one neighborhood against another, they did the math by hand.

I watched this for a while and thought: I can fix this. Build a form, a table, maybe a simple search. It should take a weekend.

I was wrong about what the problem actually was

The spreadsheet was not the problem. The problem was that land is spatial. Two plots with identical specs can have completely different values depending on where they sit on a map. A parcel next to a main road in Seminyak and a parcel the same size in a rice field outside Tabanan are not the same thing, even if the row in the spreadsheet looks identical.

Once I understood that, the whole shape of the project changed.

Building LandMap

The app I ended up building is called LandMap. It is a tool for recording land parcels and understanding their value relative to everything around them.

Every parcel lives as a point on the map, with its area in square meters, its total value, and a value per square meter that the database calculates automatically as a generated column. The public-facing page is an interactive map built with Leaflet, where every parcel shows as a marker and nearby ones cluster together so the view stays readable.

The part I am most proud of is the radius analysis. You search for any location in Bali, pick a radius from one to ten kilometers, and the app queries every parcel within that distance and returns the average, minimum, and maximum value per square meter in that area, with each parcel sorted by how far it sits from your search point. It is a simple idea, but it answers the exact question my sibling was always trying to answer by scrolling a spreadsheet and doing math by hand.

The whole stack runs on Cloudflare. SvelteKit with Svelte 5 runes on the frontend, a Workers adapter so the app runs at the edge, and D1 as the database. I also built the authentication from scratch using PBKDF2-SHA256 with session storage in the database, because I did not want to pull in a library I did not understand for something that touches access control.

The parts that were harder than I expected

Haversine distance calculations inside a database query is not something I had done before. I ended up doing a bounding-box pre-filter in SQL and then running the exact distance math in TypeScript on the filtered results. Getting that pipeline right took longer than any other part of the project.

Leaflet also does not expect to run in a Workers environment. The library assumes a browser DOM at import time, which meant I had to be careful about when and how I loaded it. I spent a few hours reading through Leaflet source code before I understood what was happening.

There is also an admin approval workflow. New parcels go in as pending, an admin reviews and approves or rejects them, and only approved data appears on the public map. Building that flow meant thinking carefully about state and permissions across the whole app, which pushed me to make decisions about architecture that I would not have made if I had just shipped a basic CRUD.

What it cannot do yet

LandMap is useful, but it is not finished. Every parcel is a single point on the map, not a polygon. That means you cannot actually draw or see the real boundary of a plot, which is the thing that would make this genuinely useful for serious land management. Real denah tanah, the actual shape and edge of a piece of land, is still missing. I did not know how to approach polygon editing when I started, and learning how to do that properly is something I still want to tackle.

The interface also assumes you already know what you are doing. My sibling can use it, but I would not hand it to someone who is not comfortable with web apps and expect them to figure it out on their own. Building for non-technical users requires a kind of care in design that I do not have enough skill for yet. That gap matters to me and it is one of the things I most want to work on.

There is no way to attach documents either. Land certificates, permits, photos of the actual land, all of that still lives somewhere else. A version of this tool that a family could actually rely on for real decisions would need to keep all of that in one place.

Why I kept going anyway

I could have stopped at the CRUD. A table with add, edit, delete, and a basic search would have replaced the spreadsheet and been useful enough. But every time I got one piece working I saw the next piece that was missing, and the project kept pulling me further.

That is what I did not expect. I thought I was building a small tool for my sibling. What I actually built was the thing that showed me how much I still do not know, about spatial data, about designing for people who are not me, about what it takes to make something reliable enough to trust with real decisions. Those gaps do not discourage me. They are the reason I want to keep building.