lgtm
This commit is contained in:
parent
982e0cc89c
commit
cfaf58dfba
44 changed files with 793 additions and 201 deletions
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Price estimation runs on ``price_inputs.parquet`` (built by ``property_base``
|
||||
straight from epc_pp + arcgis, independently of merge's area features) and emits
|
||||
``price_estimates.parquet`` — the natural key (Postcode + coalesced address) plus
|
||||
``price_estimates.parquet``: the natural key (Postcode + coalesced address) plus
|
||||
``Estimated current price`` / ``Est. price per sqm``. This step joins those two
|
||||
columns onto properties.parquet to produce the file the server consumes.
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ Why the natural key
|
|||
-------------------
|
||||
Estimates and properties are built by separate runs, so a positional row index
|
||||
would not line up. Instead both derive the key ``(Postcode, coalesce(register
|
||||
address, EPC address))`` — which is unique and non-null on the deduped dwelling
|
||||
address, EPC address))``, which is unique and non-null on the deduped dwelling
|
||||
universe (see ``property_base._dedupe_collapsed_properties``) and identical on
|
||||
both sides because both start from that same universe. So estimates map onto
|
||||
properties 1:1 regardless of row order.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue