Map My Lot

The problem

Every time I needed to check a property boundary, I hit the same wall: government mapping portals require a "lot on plan" number (e.g. Lot 5 DP 812345). Almost nobody knows this off the top of their head. It is on your Certificate of Title, not on a rates notice or a real estate listing.

The result: homeowners planning fences or renovations, investors checking land sizes, real estate agents at inspections - all frustrated by portals designed for licensed conveyancers, not ordinary people.

MapMyLot solves this with one input: a street address.

What it does

Type a street address. See the property boundary polygon on the map. Tap it to get the lot area (m2, hectares) and perimeter (metres). Toggle satellite imagery to compare the boundary against the physical property. Download a PDF for $4.99 if you need a record.

No lot number. No account for the first 5 lookups/day. Works on any device.

The data engineering story

The hardest part was not building the app - it was getting 10 jurisdictions of government spatial data into a single PostGIS database in a consistent schema.

New Zealand (LINZ): The LINZ WFS API requires the API key in the URL path as ;key=..., not in the Authorization header. This is not documented obviously. The dataset returns 5.41M features including historic parcels with null geometry - you have to filter those. Ended up with 4.26M valid parcels.

Queensland and NSW (Shapefiles, EPSG:4283): Straightforward shapefile processing with ogr2ogr, but GDA94 (EPSG:4283) needs explicit reprojection to WGS84. The NSW dataset is 4.89M parcels - too large for json.load in Python. Used ijson for streaming GeoJSON parsing, with a custom decimal encoder because ijson returns decimal.Decimal for coordinates.

British Columbia (Shapefiles, EPSG:3005): BC Albers projection (EPSG:3005), 2.48M parcels. The ogrinfo field names differ from what the LTSA documentation implies - had to inspect the actual DBF to find FEATURE_AREA_SQM (not AREA_SQM).

England and Wales (GML, EPSG:27700): The hardest ETL. HM Land Registry INSPIRE data is distributed as ~5,800 zip files, each containing GML in British National Grid (EPSG:27700). You MUST pass -s_srs EPSG:27700 to ogr2ogr explicitly or the coordinates come out wrong. Processed all files, reprojected to WGS84, loaded into PostGIS.

Tile pipeline: PostGIS -> NDJSON export -> tippecanoe (felt fork, not mapbox fork - only felt fork outputs .pmtiles natively) -> upload to Cloudflare R2. PMTiles on R2 = zero egress cost vs S3's $0.09/GB.

Runtime lookup: PostGIS point-in-polygon with a GiST index on the geometry column. Fast enough for a synchronous API response without connection pooling overhead.

Architecture decisions I'd make the same again

- PostGIS over DuckDB Spatial: I considered DuckDB on GeoParquet. The freemium gate (5 lookups/day) must be server-side or it can be bypassed. That means a real database. PostGIS is the right call.

- PMTiles on Cloudflare R2 over a live tile server: No process to maintain, free egress, global CDN. The tradeoff is tile freshness (need to regenerate and reupload when data updates), but cadastral data only changes quarterly so this is fine.

- FastAPI over Django/Rails: The app is simple. FastAPI gives async handlers, automatic OpenAPI docs, and type checking with Pydantic. No ORM needed since all queries are raw PostGIS SQL.

What I'm looking for from the IH community

- Feedback on the product (have you tried it? What would make it stickier?)

- Anyone in AU/NZ real estate, property development, or surveying - am I solving a real pain point or building for a niche that does not exist?

- Technical questions welcome - happy to go deep on the PostGIS schema, the ETL pipeline, or the PMTiles serving setup

Try it at mapmylot.com - the search bar is on the landing page.