Why Self-Organizing Maps Are So Good at Property Valuation
By Viktor Kreschenski, Kretronik GmbH · 6 August 2026
Photo by Datingjungle on Unsplash
Every property valuation eventually reduces to one question: which other properties count as comparable? German law is unusually direct about this. The Immobilienwertermittlungsverordnung (ImmoWertV 2021), in force since 1 January 2022, makes the Vergleichswertverfahren, the comparables method, the priority procedure, and requires the appraiser to work from realised purchase prices of properties whose characteristics sufficiently match the subject. What the ordinance cannot do is tell you how to decide what "sufficiently match" means.
That decision is a clustering problem wearing a legal costume. And clustering messy, high-dimensional, spatially structured data into groups of things that genuinely belong together is precisely what a self-organizing map was invented to do.
Key Takeaways
- A self-organizing map does not predict a price. It finds the properties a price should be argued from, which is what the Vergleichswertverfahren actually asks for.
- A single hedonic regression assumes one price equation holds across a whole city. Studying more than 5,000 Dallas transactions, Basu and Thibodeau (1998) found mean prices ranging from $41,311 to $259,348 across eight submarkets in one metro, with spatially correlated residuals in half of them.
- Because a SOM is unsupervised, price is never a training label. That means it can be trained on public listing data, which matters in Germany, where the sold-price Kaufpreissammlung is access-restricted.
- The trade-off is honest: a gradient boosting model will usually beat a SOM on raw point accuracy. The SOM wins on segmentation, auditability, and behaviour in thin markets.
- We run this in production. Somantic values German property with a self-organizing map, and the API returns every comparable it used. Try it via the developer portal or on RapidAPI.
Why one regression over a whole city struggles
The default quantitative approach to property valuation is the hedonic model: regress price on square metres, rooms, year of construction, and a set of location dummies. It is fast, it is interpretable, and it carries an assumption that quietly breaks in real markets. A single regression assumes that one extra square metre is worth roughly the same everywhere in the dataset, once you have controlled for the other variables.
It is not. In their study of more than 5,000 single-family transactions in Dallas between late 1991 and early 1993, published in the Journal of Real Estate Finance and Economics, Basu and Thibodeau (1998) split the metro into eight submarkets and found mean transaction prices spanning from $41,311 to $259,348. Those are different markets with different buyers, not one market with a wide spread. The authors found spatial autocorrelation in the hedonic residuals in four of the eight submarkets for properties within a 1,200 metre radius, meaning the model was systematically wrong in geographically clustered ways. When they replaced ordinary least squares with a kriged estimator that models that spatial structure, predictions improved in six of the eight submarkets.
The lesson generalises well beyond Dallas. If your residuals cluster in space, your model is missing a segmentation step. You can bolt on spatial statistics, or you can find the segments first and value inside them. The second route is where the SOM comes in.
What a self-organizing map actually does
The self-organizing map was introduced by Teuvo Kohonen in his 1982 paper Self-organized formation of topologically correct feature maps in Biological Cybernetics, since cited more than 7,000 times. The mechanism is simpler than the name suggests.
You lay out a grid of cells, typically a two-dimensional rectangle. Each cell holds a weight vector with the same shape as your input data. For a property that might be latitude, longitude, living area, room count, and year of construction. Training loops over your records, and for each one it finds the cell whose weight vector is closest, the Best Matching Unit. It then nudges that cell toward the record, and nudges the cell's grid neighbours a little as well. The neighbourhood radius and the learning rate both shrink over time.
That neighbour update is the whole trick. Because neighbours are pulled along with the winner, cells that sit next to each other on the grid end up representing similar properties. The map becomes an ordered, low-dimensional picture of a high-dimensional market. Kohonen's term for this is topology preservation, and for valuation work it is worth more than it sounds.
Five reasons the SOM fits property valuation
1. It returns comparables, not just a number
This is the argument that matters most, and it is a structural property of the algorithm rather than a feature someone bolted on. A SOM assigns every property in your dataset to a cell. When you value a subject property, you locate its Best Matching Unit and you have, by construction, the list of properties the model considers comparable. The estimate is a function of those listings, and you can print all of them.
Contrast that with a gradient boosting model. It may well produce a tighter point estimate, but ask it why, and the honest answer is a set of SHAP values, not a set of properties. When a client, a lender, or a court asks which comparables supported the figure, "feature 7 contributed 4.2%" is not a usable answer. The ImmoWertV framework is built around identifiable comparable cases, so a method that produces them natively is working with the regulation instead of against it.
2. It discovers submarkets instead of assuming postcodes
Most valuation systems use administrative geography as a proxy for market segment: postcode, district, Census tract. These boundaries were drawn for postal routing and statistics, not for housing economics, and they cut straight through real submarkets while merging unrelated ones.
Data-driven segments do better. In A Machine Learning Approach to Delineating Neighborhoods from Geocoded Appraisal Data (Ali, Graves, Wu, Lee and Linstead, ISPRS International Journal of Geo-Information, 2020), the authors built neighbourhoods by clustering properties that appraisers had actually used as comparables for one another. Those learned neighbourhoods explained more of the variation in valuation, square footage and price per square foot than ZIP codes or Census tracts did. They also grew and shrank across years as submarkets shifted, which fixed boundaries cannot do.
A SOM produces this kind of segmentation directly. Because latitude and longitude are just two more features rather than a hard filter, a cell can span a district boundary where the market genuinely continues, and split a single postcode where it genuinely does not. That is the empirical question, answered empirically. The approach has a long track record: Kauko, Hooimeijer and Hakfoort (2002), writing in Housing Studies, used a SOM on the Helsinki market and found that submarket formation was driven by relative location and house type, producing overlapping circular and sectoral patterns rather than the tidy concentric rings the textbook model predicts.
3. Topology preservation gives you a safe fallback in thin markets
Every valuation system meets the same failure case: a property with too few close matches. A rural house, an unusual layout, a segment with almost no current listings. A rule-based comparables engine hits its minimum count and either widens its radius blindly or gives up.
Topology preservation turns that into a controlled operation. If the Best Matching Unit holds only three listings, you expand into the immediately adjacent cells, and you already know those cells hold similar properties, because that is the invariant the training procedure enforces. You degrade along a gradient of similarity instead of falling off a cliff at a postcode boundary. You can also report how far you had to expand, which is a genuine confidence signal that costs nothing to compute.
4. It never needs a sold price, which is decisive in Germany
This is the point that generic write-ups on the topic miss, and in the German market it is close to decisive.
Under § 195 of the Baugesetzbuch, notaries must send a copy of every property transfer contract to the responsible Gutachterausschuss, which maintains the Kaufpreissammlung. So the sold-price data exists, and it is excellent. It is also purpose-bound: access to extracts requires a legitimate interest, publishing individual prices is not permitted, and what reaches the public is aggregated and anonymised. If your model needs sold prices as training labels, that is a hard constraint on what you can legally build.
A SOM sidesteps it, because it is unsupervised. Price is not a training target. The map organises on structural and locational features, and prices are read off each cell after the fact, as a summary of whatever data you legitimately have. That means public listing data across the German portals is a workable training set. You are still measuring asking prices rather than sold prices, and you should say so plainly rather than pretend the gap does not exist. But you get a live, national, legally clean view of market structure, updated as listings appear, and you can calibrate the asking-to-sold gap separately using published Gutachterausschuss aggregates.
5. You can inspect the entire model on one screen
A trained SOM is a small grid. Shade the cells by median price per square metre and you can see the market's structure at a glance: where the expensive segments are, whether the transition between them is smooth or abrupt, which cells are nearly empty. Shade the same grid by year of construction or by average size and you can read off what actually distinguishes one segment from another.
This is not a presentation nicety. Model review is a real cost, and most machine learning models are reviewed through aggregate error metrics that hide local failures. A hole in your coverage is visible on a SOM as an empty cell, immediately, without anyone having to think to test for it.
How we use this in Somantic
This is not theory for us. Somantic, our real estate intelligence platform for the German market, runs a self-organizing map in production as its valuation layer. It aggregates listings from the major German portals, and the map is trained on that aggregated feed. The feature vector is latitude and longitude, living area, room count, and year of construction. A subject property is matched to its Best Matching Unit, and the price and rent estimates are derived from the active listings in that cell. Everything described above, including the thin-cell fallback into neighbouring cells, is the actual production behaviour.
The design consequence shows up in the API contract. The valuation endpoint returns a price estimate, a rent estimate, and a similar_properties array containing every comparable used, each with its source portal, price or rent per square metre, room count, year of construction, and a link to the original listing. We could return only the number, and the response would be smaller. Returning the comparables is the point: it is what makes the estimate checkable by someone who disagrees with it.
There are two ways to call it. The developer portal at somantic.net/developers gives you direct access with documentation and a web UI for trying queries, independent of any third-party platform. The same valuation API is also published as Property Valuation Germany on RapidAPI for teams that prefer RapidAPI's keys and billing. Both speak the same request format:
import requests
url = "https://property-valuation-germany.p.rapidapi.com/api/estimate"
payload = {
"street": "Admiralsbogen 45",
"postcode": 80939,
"square_meters": 100.5,
"rooms": 2.5,
"year_of_construction": 1990,
"typ": "wohnung", # Use "haus" for a house
"city": "Muenchen"
}
headers = {
"x-rapidapi-key": "YOUR_RAPID_API_KEY",
"x-rapidapi-host": "property-valuation-germany.p.rapidapi.com",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers)
print(response.json())
The underlying listing data is queryable on its own through the Somantic GraphQL API. We covered how that works in an earlier post: One GraphQL API for Germany's Real Estate Portals.
Where a SOM is the wrong tool
An article that only lists strengths is marketing. Here is where this approach genuinely loses.
- Raw point accuracy. If your only metric is error against sold prices and you have labelled sold data to train on, a gradient boosting model will normally beat a SOM. The SOM is a segmentation method with a valuation step attached, not an optimised price predictor. Do not claim otherwise.
- Quantization error. Every property in a cell is treated as equivalent to the cell's prototype. Genuine within-cell variation gets flattened. Finer grids reduce this and simultaneously thin out each cell, so grid size is a real trade-off, not a hyperparameter you can tune once and forget.
- Feature scaling dominates the result. The Best Matching Unit is chosen by distance, so how you scale latitude against square metres silently decides whether the map organises primarily by location or primarily by size. This choice deserves explicit justification and testing.
- No native uncertainty estimate. A SOM gives you a cell, not a confidence interval. You have to construct one, for instance from within-cell price dispersion and the number of comparables found.
- Unique properties stay hard. A castle, a converted watermill, or a listed building with no analogue in the dataset will land in some cell, and that cell will be wrong. Clustering cannot invent comparables that do not exist, and a system that fails loudly here is better than one that returns a confident number.
The sensible architecture in most cases is a hybrid: use the SOM to establish the submarket and produce the comparable set, then run a supervised model or a straightforward adjustment procedure within that segment. You get the segmentation and the audit trail from the map, and the point accuracy from the model on top. A systematic review of mass appraisal models published in Sustainability in 2019, covering the literature from 2000 to 2018, identifies exactly this kind of mixed AI and GIS approach as the direction the field has been moving.
How to check whether any of this is working
Whichever method you choose, evaluate it with ratio study statistics rather than with a single error figure. The IAAO Standard on Ratio Studies is the reference the assessment profession uses, and it gives concrete thresholds.
- Median ratio of estimated value to actual price should sit between 0.90 and 1.10. This catches systematic over- or under-valuation.
- Coefficient of dispersion (COD), the average absolute deviation from the median ratio divided by the median, should be under 15 for residential property, and 5 to 10 for newer or fairly similar homes. This is the primary indicator of uniformity.
- Trim outlier ratios before computing COD, since the statistic is highly sensitive to them. Dropping values beyond three times the interquartile range is the usual approach.
Compute these per SOM cell, not only across the whole dataset. A model with an acceptable overall COD can still be badly miscalibrated in specific segments, and per-cell statistics are what surface that. This is another practical benefit of segmenting first: your evaluation gets the same structure as your model, so a local failure has somewhere to show up.
The short version
Property valuation is a comparables problem, German law says so explicitly, and a self-organizing map is a comparables engine that happens to have been invented for a different purpose in 1982. It discovers submarkets rather than inheriting them from the postal service, it degrades gracefully when data is thin, it trains without ever touching a restricted sold price, and it hands back the evidence along with the number.
It will not win a point-accuracy benchmark against a well-tuned gradient boosting model, and anyone telling you otherwise is selling something. But a valuation you can defend is usually worth more than a valuation that is marginally closer and cannot be explained.
Frequently asked questions
What is a self-organizing map?
A self-organizing map (SOM), introduced by Teuvo Kohonen in 1982, is an unsupervised neural network that projects high-dimensional data onto a two-dimensional grid of cells. Each cell holds a weight vector. Training moves the winning cell and its grid neighbours toward each input, so nearby cells end up representing similar records.
Why is a self-organizing map good for property valuation?
Property valuation is fundamentally a comparables problem, and a SOM is a comparables engine. It clusters properties by location, size, layout and age, then returns the actual listings in the winning cell. You get an estimate plus the evidence behind it, which matches how the German Vergleichswertverfahren is supposed to work.
Is a self-organizing map better than regression for house prices?
Not better at raw point accuracy. A gradient boosting model usually wins there. A SOM is better at segmentation and explainability: it discovers submarkets rather than assuming one price equation holds citywide, and it hands back the comparable properties, which a regression coefficient cannot do.
Can a self-organizing map be trained on asking prices instead of sold prices?
Yes, and this matters in Germany. A SOM is unsupervised, so price is never a training label. It clusters on structural and locational features, then reads prices off the cluster afterwards. Since the Kaufpreissammlung of sold prices is access-restricted, public listing data becomes a workable training set.
How do you measure whether a property valuation model is accurate?
Use ratio study statistics from the IAAO Standard on Ratio Studies. The median ratio of estimate to actual price should fall between 0.90 and 1.10, and the coefficient of dispersion should be under 15 for residential property, or 5 to 10 for newer and fairly similar homes.
See it working on real German listings
Somantic values German property with the self-organizing map described in this article, and every estimate comes back with the comparable listings behind it. Read the API docs at the developer portal, or get a key on RapidAPI.