# Location & geography Where a property *is* matters as much as what the property *is*. Travellers filter by destination, partners route inventory by region, your reporting rolls up by city, district, and neighborhood. **Location & geography** is how you record where every property sits in the world — precisely enough that *"properties within 2 km of Konyaaltı Beach"* returns exactly the right list. ## What the catalog records For each property, location data has three layers: | Layer | What it carries | | ----------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Coordinates** | Latitude and longitude — used by maps, distance calculations, "near me" search. | | **Place hierarchy** | Country → region → city → district → neighborhood — used by filters, search facets, and per-region operations. | | **Landmarks & nearby places** | Notable points the property is near (a beach, a train station, a museum, an airport). | Each layer plays a different role. Coordinates pinpoint; the place hierarchy classifies; landmarks contextualize. ## The place hierarchy The platform's place taxonomy is a typed tree: * **Country** — the top level (e.g. Turkey, Spain, Portugal). * **Region** — the level immediately below the country (e.g. *Antalya*, *Andalusia*, *Algarve*). Different countries can use different terms (region, province, state, autonomous community); the platform models them all the same way. * **City** — the city or town the property is in. * **District** — a sub-city division where it exists (a borough, a neighborhood district). * **Neighborhood** — the most local level — a named neighborhood, a small village. Some countries skip a level (small countries may not have a meaningful district level; large countries may have multiple intermediate levels). The platform handles partial hierarchies cleanly — what is missing is missing, not faked. ## Why coordinates matter on top of the hierarchy The hierarchy is good for filters and rollups. Coordinates are what enable: * **"Within 5 km of the beach" search** — distance is calculated from the property's coordinates. * **Map-based browsing** — properties pin to a map. * **Per-radius reporting** — *"every property within 10 km of the new convention centre"*. * **Walking-distance contextualization** — *"5-minute walk to the metro"* surfaces on the property page. Without good coordinates, every "near" or "within" query fails or returns approximations. ## Landmarks and nearby places Beyond the place hierarchy, properties carry references to specific points the traveller cares about: * **Beaches, parks, public squares, viewpoints.** * **Transport hubs** — airports, train stations, metro stations, bus terminals. * **Cultural and entertainment** — museums, theatres, stadiums, convention centres, theme parks. * **Commercial** — major shopping districts, market squares. For each landmark, the catalog records a distance and (optionally) a walking time. These show on the property page and feed the search-side context — *"5-minute walk to Konyaaltı Beach"*. ## How locations get set When you onboard a property, location is one of the first things you set. A typical pass: 1. **Drop a coordinate pin** on the map for the property's exact spot. 2. **The place hierarchy auto-resolves** — country, region, city, district, neighborhood are identified from the coordinate. 3. **You confirm or correct** — auto-resolution sometimes gets the neighborhood wrong in dense urban areas (e.g. a property on a boundary street between two named neighborhoods); you fix it manually. 4. **You add landmarks** — pick from suggested nearby places within 1–2 km, or search and add specific ones (e.g. *"Antalya Airport"*, *"Lara Beach"*). 5. **You verify on the property page** — the location renders the way travellers will see it. [AI Resolve](/console/catalog/ai-resolve.md) is the assist that makes step 2 fast — given a coordinate or an address, the place hierarchy fills in cleanly. ## Per-language place names The place hierarchy carries multilingual names: *İstanbul* / *Istanbul*, *İzmir* / *Izmir*, *Konyaaltı* / *Konyaalti*. Travellers see the place name in the locale they request; partner channels receive whichever locale they ask for. You do not have to maintain translations for every place — the canonical place taxonomy ships with multilingual names for the major levels. ## Per-channel exposure Location data is rarely hidden — almost every channel needs at least the basics. But the level of detail varies: * A high-fan-out metasearch feed wants coordinates and city; landmarks may be irrelevant. * A B2B aggregator might consume the full hierarchy plus all landmarks for its own filtering. * A direct-booking page can render the most context-rich version — coordinates, hierarchy, landmarks, walking-distance hints, the lot. The platform sends each channel what it asks for; what does not fit is not stripped from the canonical record. ## Adragent and locations Common phrases that map to Adragent location operations: * *"Set the location of the new Hotel Sunrise to coordinates 36.85, 30.78 and resolve the neighborhood."* * *"Find every property in Antalya without a beach landmark within 1 km."* * *"Show me properties where the auto-resolved district disagrees with what the operator set."* * *"Add the Konyaaltı Beach landmark to every Antalya property within 2 km of it."* Read operations return immediately; writes preview before applying. ## Where to next * **The AI Resolve operator action that bootstraps location and content** → [AI Resolve](/console/catalog/ai-resolve.md) * **The categories that pair with location for search** → [Categories](/console/catalog/categories.md) * **The top-level catalog object location attaches to** → [Property](/console/catalog/property.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://adrasis.gitbook.io/console/catalog/location-geography.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.