A back office for an Israeli land and real-estate company to manage its parcel portfolio by block and parcel number. A background worker looks up each parcel's address from the national GIS service, and one click opens the parcel highlighted on the national map. Before, both were done by hand.
In Israel, land is identified by a block number and a parcel number. The company tracks a large portfolio of them, each with an ownership type, a registration method, a land-use designation, an area, sub-parcels and supporting documents. Two everyday tasks were manual. Finding a parcel's street address meant searching the national GIS portal one parcel at a time and copying the result. Seeing where a parcel is meant opening the portal again and typing the numbers in. Nobody could easily tell which records were still missing data.
The diagram is wider than the screen: swipe sideways to see all of it →
The worker runs inside the API host, so there is nothing extra to deploy. It keeps the raw GIS response next to the parsed address for auditing, and the list endpoint leaves that column out so list pages stay light.
A record counts as “complete” when it has an address, an area and a land use. SQL Server computes and stores that flag, so the list can show and sort by status with no application code to keep in sync. Trade-off: changing the rule needs a schema change, not a config change.
The worker picks parcels that have never been updated, in small ordered batches, and spaces its calls 100 ms apart. New parcels get enriched automatically, and a restart carries on from where it stopped. Trade-off: addresses fill in over minutes instead of instantly.
The admin loads the national GIS JavaScript map and highlights the block and then the parcel. The client gets the official cadastral layers for free. Trade-off: a third-party script with a jQuery dependency and its own load timing, which needed careful handling (see below).
Filters, sorting and paging are written to the query string and read back on load. A filtered view survives a refresh and can be sent to a colleague as a link. Trade-off: more parsing code, including multi-value filters.
A parcel can have any number of sub-parcels. Keeping them inside the parcel record made filtering and validation awkward.
Moved sub-parcels into their own table with a unique (parcel, sub-parcel) key. On update the set is replaced as a whole, so there are no partial edits.
The same block and parcel could be entered twice. That would split media and history across two records.
Added a unique index on block + parcel, so the database rejects duplicates no matter which path the data comes in by.
Users lost their filters and page whenever they refreshed or followed a link. Defaults also overwrote values that came from the URL.
Moved table state to the query string with typed parsing. Defaults now apply only when a value is missing. Page size is standardised at 100 and the default sort is block, then parcel.
The national map script loads asynchronously. Highlighting a parcel before the map had initialised failed without any error.
Load the script on demand, poll for the map API every 100 ms (7 s timeout), and run the block and parcel highlight only once both the map and the parcel data are ready.
Some block/parcel pairs return no match or an error from the GIS service.
Each parcel is wrapped on its own and logged with its block and parcel. A failed batch backs off before the next cycle. Empty results never overwrite an existing address.
Each parcel needs documents: external links, uploaded files, or both.
Built one media form that sends multipart/form-data to the API, which stores files in S3. On edit, the existing file is kept unless a new one is uploaded.
Step times are conservative estimates for illustration, not measurements. The “after” address step runs with nobody involved.
Free scoping call · 30 minutes · No commitment
Write a few lines: the process or system, what hurts today (time, errors, cost or an AI pilot that stalled) and who uses it. After a short call you get a written plan and a fixed quote within ≈3 days.
Opens a pre-filled email · reply within one business day
The model reads. The code counts.
All projects