One hotel, five names: the quiet craft of hotel mapping

A bedbank calls it “Grand Hyatt Dubai.” A second supplier sends “Hyatt Grand, Dubai.” Another adds an airport code, abbreviates the road and pins the property several metres away.

To a traveller scanning the results, these appear to be one hotel. To an aggregation system, they are three records with different identifiers, text and content quality.

If they appear as separate cards, more supply has produced a worse product. Reviews fragment. The customer compares duplicates instead of rates. One listing appears sold out while its twin is available. Analytics count demand several times.

Hotel mapping is the work of turning that supplier noise into a canonical property without erasing real distinctions. It is not data cleaning after aggregation. It is the foundation that makes aggregation useful.

This essay is the overview: the three problems hiding inside the word "mapping," the cost of getting each one wrong, and how to tell whether a platform has actually solved them. The stage-by-stage pipeline that does the collapsing, from normalisation and blocking through calibrated matching, review queues and drift control, has its own essay: How we solved room mapping.

There are three mapping problems

“Hotel mapping” often compresses several different tasks.

These layers interact but cannot share one universal similarity score. Two properties may share a resort address; two similar room names can hide different bedding. Content authority also varies by field.

Begin with a canonical property identity

A canonical record is not another supplier listing. It is the stable entity to which listings attach.

Useful evidence includes:

• Geographic distance and coordinate confidence.
• Normalised street address and postal code.
• Telephone numbers and domains.
• Chain, brand and property identifiers.
• Name tokens after removing generic words and location suffixes.
• Neighbourhood and landmark context.
• Content evidence such as matching photos.

No field is trustworthy alone. Coordinates can point to a city centre, names change after rebranding and addresses vary by language.

Use a layered resolver:

1. Blocking generates plausible candidates using location, brand or address so every listing is not compared with every property.
2. Feature scoring evaluates independent evidence instead of raw string similarity alone.
3. Conflict rules prevent dangerous merges, such as distinct unit numbers or known properties in one complex.
4. Decision thresholds separate auto-match, human review and new-canonical creation.
5. Versioned provenance records why the match happened and which model or rule decided it.

High-confidence matches can flow automatically; ambiguous pairs deserve a review queue with maps, side-by-side content and a reversible decision. Record the evidence at decision time. A score without its inputs is difficult to audit after a supplier feed changes.

Precision and recall have asymmetric costs

A missed match creates a duplicate; a false match may send a traveller to the wrong building. That asymmetry favours precision at the automatic-merge threshold. Use a lower threshold to generate candidates without committing identity.

Calibrated well, the split is not close. Across OnArrival's graph of 2M+ properties, around 97% of listings resolve automatically and fewer than 0.1% ever surface as duplicate cards. The remainder goes to a human review queue, and each reviewed pair feeds the next calibration round, which is why the review band narrows over time instead of growing with the catalogue.

Measure more than an overall accuracy percentage:

• Precision of automatic matches.
• Recall of known duplicate pairs.
• False merges by geographic density.
• Duplicate exposure in customer search results.
• Time to resolve review-queue items.
• Reopened mappings after supplier or brand changes.

OnArrival’s Hotels page describes canonical property IDs built from geo, address, phone and content signals. The general lesson is that mapping quality should be observable in the customer surface, not only in an offline model score.

Room mapping is the sharper edge

Property identity answers “Which building?” Room mapping answers “Which experience inside it?” Supplier language makes this difficult:

• “Garden View Double”
• “Standard Garden Facing”
• “Twin Room, Garden Side”

These might be the same inventory. One may also have two single beds while another has one double. A careless merge makes the cheapest rate look comparable when it is not.

Extract structured room attributes before comparing names:

• Occupancy and age rules.
• Bed type and count.
• View, floor or building wing.
• Room size when supplied.
• Smoking policy.
• Accessibility features.
• Board basis such as room-only or breakfast.
• Refund and payment conditions.

Separate room type from rate plan. A deluxe king can have refundable, non-refundable, breakfast and member-rate plans. Those plans should compete within the correct room identity, while their commercial conditions remain visible.

When evidence is incomplete, use conservative groups such as “similar rooms” rather than asserting equivalence. The interface can still help the traveller without fabricating certainty. Unknowns deserve asymmetric handling: a missing view can merge with a stated view when everything else agrees, but a conflicting bed configuration is a veto, because bedding is the attribute guests feel most when it is wrong. The parsing grammar behind those rules, and the drift control that keeps room mappings current as suppliers rename rooms, are covered in the room-mapping deep dive.

Merge fields, not whole records

Choosing one supplier as the “master record” wastes evidence. A chain-direct source may be best for the current name and official amenities; a mapping source may have cleaner geography; a wholesaler may have a unique rate but weak photos.

Build field-level lineage:

In practice that means provenance lives per field, not per record. The canonical entity is closer to this than to any single supplier payload:

{
  "property_id": "prop_7f21",
  "fields": {
    "name":        { "value": "Grand Hyatt Dubai", "source": "chain_direct", "as_of": "2026-07-12" },
    "coordinates": { "value": [25.2262, 55.3325], "source": "verified_geocode", "confidence": 0.98 },
    "amenities":   { "taxonomy": "canonical_v4", "evidence": ["bedbank_a", "chain_direct"] }
  },
  "listings": ["bedbank_a:HTL99213", "bedbank_b:AE-3321", "chain_crs:GHDXB"]
}

Every displayed value should be replaceable without changing the canonical property ID. That is how a rebrand updates content without breaking saved trips, reviews or analytics.

Image deduplication is part of comprehension

Supplier feeds often repeat the same lobby photo in different crops. Combine perceptual similarity, sharpness and scene classification to group near-duplicates, choose the best representative and balance the gallery across exterior, room, bathroom, dining and amenity scenes.

Do not let aesthetic scoring hide evidence: an accessible bathroom or honest room view may be more useful than another polished lobby.

Rate comparison comes after identity

Once property and room mappings are stable, rates can compete on meaningful terms. “Lowest rate” should mean a comparable total, not the smallest number extracted from a feed.

Normalise:

• Total price for the stay.
• Included and excluded taxes or fees.
• Currency and conversion context.
• Payment timing: now or at property.
• Cancellation schedule and deadlines.
• Meal plan and occupancy.
• Loyalty eligibility or member restrictions.

Then preserve supplier-specific fulfilment data behind the selected rate. The customer sees one hotel card and clear options; the order system knows which supplier must confirm and service the booking.

Mapping does not remove choice. It removes accidental repetition so the meaningful choices become visible.

Handle change as a first-class event

Properties rebrand, split towers, close temporarily or move between chains. Suppliers can reuse identifiers. A canonical catalogue needs history.

Store mapping decisions as versioned relationships with provenance. Support merge, unmerge, alias and successor operations. Before merging, examine effects on bookings, saved items, reviews and analytics.

Create monitors for:

• Large coordinate moves.
• Sudden name and brand changes.
• Conflicting phone or domain evidence.
• A surge of unmatched listings in one market.
• Previously mapped rooms drifting in attributes.
• Customer searches that expose near-identical cards.

Mapping is never “finished.” It is a continuously maintained knowledge graph tied to live commercial inventory.

A practical evaluation exercise

When evaluating a hotel supply or mapping platform, bring a deliberately messy set:

1. One property represented by several suppliers.
2. Two neighbouring hotels in the same complex.
3. A recently rebranded property.
4. Equivalent rooms with inconsistent names.
5. Similar rooms with different bedding.
6. Rates that differ in taxes, breakfast and cancellation.

Ask the provider to show the canonical property, the match evidence, the review path, the room grouping, the field provenance and the final rate comparison. Then unmerge a deliberately incorrect pair and show which saved trips, analytics and live offers are repaired. That last step reveals whether mapping is a maintained product or a one-way import.

A large hotel catalogue is not automatically a coherent catalogue. The quality is in the identity decisions a traveller never has to notice.