A property's address and the destination travellers use to find it do not always follow the same hierarchy. Adrasis stores both truths in one place catalog, with shared identities and two distinct axes. Addresses remain faithful to official geography, while search boxes and destination filters use travel language.
What the catalog records
Each property location consists of five separate pieces of data:
| Layer | What it carries |
|---|---|
| Coordinates | Latitude and longitude: the property's position on the map, and the point its nearby landmarks are measured from. |
| Shared place identity | One record and one stable public_id for each real place. |
| Administrative axis | The country-specific structure used for official addresses, forms, and administrative reporting. |
| Destination axis | The destination structure used for search, filtering, and traveller-facing discovery. |
| Landmarks | Nearby points such as beaches, airports, stations, or museums. |
These pieces are not interchangeable. Coordinates identify a point, the two geography axes classify that point for different purposes, and landmarks describe its surroundings.
One place, one identity
The same real place is not duplicated for the administrative and destination axes. It has one shared record and one public_id. Its type, parent, or display name may differ between the axes, but its identity remains the same.
A destination that has no single administrative counterpart has its own record. Istanbul city, which spans multiple districts, and Cappadocia, which is not an official address level, are examples. These records still belong to the same shared place dictionary.
Two axes, two questions
| Axis | Question it answers | Where it is used |
|---|---|---|
| Administrative axis | What is the property's official address? | Address entry, local compliance, administrative reporting, and data validation. |
| Destination axis | Under which place does a traveller search for this property? | Search boxes, destination filters, your online shop (web, iOS, Android), and partner distribution. |
Search uses one place list: the destination dictionary. The administrative axis is not a second search classification, and clients do not choose between two trees. When a destination is selected, property membership is determined through destination-axis relationships.
Administrative geography in Turkey
The Turkish address axis follows the order Province → District → Neighborhood.
For example, the administrative chain for a property in Caferağa is Istanbul (Province) → Kadıköy (District) → Caferağa (Neighborhood). No artificial city level is inserted, and a missing level is not invented.
The destination axis can make the same property searchable under Istanbul (City) → Kadıköy (District). Istanbul city is a separate destination record from Istanbul province. Kadıköy is represented by the same public_id on both axes.
Destination types
The destination dictionary uses the following types that carry meaning in travel search:
| Type | Meaning | Example |
|---|---|---|
province_state |
A country's top subdivision and a broad search scope. Its label in Turkey is Province. | Istanbul province |
city |
A destination travellers understand as a city or settlement. | Istanbul, Bodrum |
district |
A sub-city destination that is administratively a district. | Kadıköy, Beşiktaş |
neighborhood |
A smaller settlement or travel quarter within a city or district. | Bostancı, Sultanahmet |
area |
A curated tourism area that does not depend on formal administrative boundaries. | Cappadocia, Turkish Riviera |
There is no generic region type. Top administrative subdivisions use province_state, while selected tourism regions use area. Landmark and airport records identify specific points; they do not define a property-search scope in the destination tree.
Examples where the axes differ
The two axes can carry different but compatible facts about the same place:
| Place | Administrative axis | Destination axis | Identity |
|---|---|---|---|
| Kadıköy | Kadıköy, District; parent is Istanbul province | Kadıköy, District; parent is Istanbul city | Same public_id |
| Bodrum | Bodrum, District | Bodrum, City | Same public_id |
| Afyonkarahisar Merkez | Merkez, District | Afyonkarahisar, City | Same public_id |
The axis-specific name in the Merkez example is intentional. The official address name is Merkez, while the city travellers search for is Afyonkarahisar. The same identity therefore reads as Merkez / district on the administrative axis and Afyonkarahisar / city on the destination axis.
Why coordinates and landmarks stay separate
The place axes tell you which classifications a property belongs to. Coordinates and landmarks describe where the property actually stands:
- The results map shows each property at its coordinates. Your web shop shows the map once your organization connects its own map key; the iOS and Android apps show it on their own. See Destination search.
- Search this area on that map lists the properties whose coordinates fall inside the area on screen.
- "Five-minute walk to the metro" descriptions use the relationship between the property and a landmark.
A landmark is not an address level or a destination parent. A coordinate does not replace a place identity. Keeping them separate puts every property in the right spot on the map without confusing administrative boundaries with points on the ground.
An area and a radius are different searches. On the shop map, Search this area uses the visible map boundaries. API partners can also search within a chosen distance of coordinates or a named place, such as within 5 km of an airport, and order the results by distance. That radius does not change a property’s address or destination membership.
How locations get set
A typical property onboarding flow is:
- Enter the property's address and exact coordinates.
- Resolve and verify the country-appropriate administrative chain.
- Link the property to the destination axis through shared place identifiers.
- Review ambiguous cases such as dense cities and boundary locations.
- Add nearby landmarks as separate relationships.
Content suggestions speeds up the process by proposing administrative places from an address and coordinates and preparing the appropriate destination connection. You can review suggestions before they are applied.
Per-language place names
Place identity is independent of language. Names such as İstanbul / Istanbul and İzmir / Izmir change by locale, but the public_id does not.
A destination name can also differ from the official address name. In the Afyonkarahisar Merkez example, both English and Turkish views use Merkez on the administrative axis and Afyonkarahisar on the destination axis. This difference does not create another place identity.
Per-channel visibility
Different channels may display different levels of detail, but they do not change shared identifiers or the meaning of the axes:
- Address fields and address reports use the administrative axis.
- Search and destination filters use the destination axis.
- The results map and its Search this area action use coordinates.
- Nearby-place descriptions use landmark relationships.
This separation prevents partners from having to infer a classification and preserves the same place identity across every channel.
AI Operator and locations
You can give the Adrasis AI Operator tasks such as:
- "Verify the new Hotel Sunrise's address and coordinates, then propose its administrative chain."
- "Show properties in the Kadıköy destination."
- "Find properties whose administrative district and assigned destination do not agree."
- "List the available properties in Antalya's Konyaaltı district for 14 to 16 October, cheapest first."
Read operations return results directly. Write operations are previewed before they are applied.
Where to next
- The Content suggestions operator action that prepares location and content → Content suggestions
- The classifications used alongside location in search → Categories
- The top-level catalog object that owns location → Property
- How a destination search orders, filters and maps its results → Destination search