When evaluating the relevance of parking query results, it’s essential to consider the user’s intent and expectations. According to the General Guidelines (GL) 5.17, if the query mentions “parking,” assume the user is looking for any available parking options, including lots, garages, and street parking. However, if the query indicates a specific type of parking, such as “free parking” or “handicap parking,” the results should match the user’s request.
Location intent is another crucial factor. As per GL 2.3.1, if the query explicitly mentions a location, the user expects to find parking near the specified area. If no location is provided, use the user’s location and viewport to infer the expected results area, as users generally expect to find parking near their current location or within the visible map (GL 2.3.2).
Distance becomes more critical in urban areas with numerous parking options. GL 5.4 and 5.6 state that results closer to the location intent should be rated higher than those further away. However, in areas with limited parking, be more lenient when considering distance (GL 5.4 and 5.7). Additionally, the prominence of a parking facility can influence relevance. For example, a large, well-known parking garage may be more relevant than a smaller, less prominent lot, even if slightly further away (GL 5.3 and 5.5).
By carefully considering these factors and referring to the relevant guideline sections, you can accurately assess the relevance of parking query results, ensuring that users are presented with the most valuable and convenient options.
Query: חניה רחוב ז’בוטינסקי, תל אביב, ישראל (Parking Jabotinsky Street, Tel Aviv, Israel) User location: 32.083984375, 34.78515625
Viewport Age: Fresh
Query Locale: he_IL
Centre Viewport: 32.0833333333333, 34.7833333333333
Result: חניון גן העיר (Gan Ha’ir Parking Garage)
Address: רחוב אבן גבירול 71, תל אביב-יפו, ישראל (Ibn Gabirol Street 71, Tel Aviv-Yafo, Israel) Classification: חניה (Parking)
Type: BUSINESS
Coordinates: 32.08157696953764, 34.779948574211154
Correct Relevance rating: Good/Acceptable
Explanation: When we rate relevance for a parking query like, חניה רחוב ז’בוטינסקי, תל אביב, (Parking Jabotinsky Street, Tel Aviv, Israel), it’s all about understanding the user’s need for parking near their specified location. Our task is to check how well Gan Ha’ir Parking Garage’s result matches this need.
The key points to consider are:
Considering these aspects, the correct rating for Gan Ha’ir would be Good or Acceptable. Here’s why:
This thinking aligns with sections 5.17 and 10.7.6 of GL, focusing on how distance and available alternatives affect parking search ratings.
Example – Relevance Rating for Ambiguous Query with Prominent POI Result Query:
Query: יפ ו (Jaffa)
User location: 32.053824336894415, 34.75559743540091
Viewport Age: Fresh
Query Locale: he_IL
Centre Viewport: 32.054865549510126, 34.758384219931536
Result: נמל יפו (Jaffa Port)
Address: יפו, תל אביב-יפו, ישראל (Jaffa, Tel Aviv-Yafo, Israel)
Classification: נמל (Harbor)
Type: BUSINESS
Coordinates: 32.05281645658546, 34.74955474552684
Correct Relevance rating: Good
When we evaluate the relevance of a broad query like “יפו” (Jaffa), we aim to determine how well the result, Jaffa Port, aligns with what might be sought. This task hinges on interpreting an ambiguous query and assessing the prominence of the result provided.
Key considerations include:
Therefore, we rate the relevance of Jaffa Port as Good for this query.
Here’s our rationale:
This approach mirrors section 5.3 of the GL, emphasizing the role of prominence when a query’s intent is unclear.
When rating pin accuracy for businesses located in buildings with multiple street numbers or businesses under one roof, follow this workflow to ensure accurate and consistent results. First, identify the result type (business/POI or address) as per section 2.2: Result Types of the GL. Next, understand the location intent, which may be explicitly stated in the query or implicitly derived from user location and viewport (refer to section 2.3: Location Intent of the GL).
Research the result using official resources like the business’s website, social media pages, and maps. If unavailable, consult reliable sources such as street imagery, recent articles in primary publications, and crowdsourced user review sites (see section 6.1: Research Expectations of the GL). To determine the boundaries of the feature, apply the Half ‘n’ Half rule (section 9.1.3.1 of the GL) for buildings in dense areas without clear dividers— research to determine boundaries for features without rooftops.
Evaluate pin placement based on the best available evidence. If street-level imagery or other strong evidence confirms the specific location within the building, only that location is Perfect. If the location cannot be confirmed but the rooftop is identified, the entire rooftop is Perfect. If multiple rooftops share the same address and the specific rooftop cannot be confirmed, all rooftops are rated Can’t Verify (refer to sections 9.2: Single Rooftop and 9.3: Multiple Rooftops of the GL).
Consider special cases like leaning buildings (section 9.2.1) and residential properties with multiple buildings (section 9.2.2).
For pin accuracy in Israel, always start with the Israeli Government Map, checking its “Streets and Structures” or combined “Streets and Structures with Satellite” layers (CSGL_IL 6.3.1). If these aren’t clear, you can look at street-level images from the last decade. Since street numbers are usually stable, I prefer street-level imagery for the final pin placement if discrepancies arise.
When it comes to businesses or POIs, use the same government map initially (CSGL_IL 6.3.2). If a business claims an address not on the map or appears differently than ground or satellite views, consider the pin accurate if it aligns with the government map or what’s observed on the ground. Trust street-level imagery, especially when it matches official records for the business or POI. However, if you can’t reconcile differences or lack imagery to confirm, mark the pin as Can’t Verify for accuracy.
Query: 15 15) נצח ישראל Netsach Israel Street)
Result: 15) רחוב נצח ישראל 15, תל אביב-יפו Netsach Israel Street, Tel Aviv-Jaffa)
Pin: 32.077754, 34.780425
When we assess the accuracy of a rooftop pin for 15 Netsach Israel Street, we want to ensure that the pin correctly represents the property’s location. In this example, we’re comparing data across different layers to determine our rating.
Here’s how we break it down:
The Satellite layer on TryRating and GovMap’s Perfect location suggest the pin is accurately placed on the rooftop.
However, the vector layer on TryRating indicates the pin is in front of the building, not directly on top of it.
Given these observations, even though we usually prefer the more favorable layer, we have a specific situation due to the building’s unique structure — it’s leaning. This detail means that although the pin appears correct in some views, we must consider the precision relative to the building’s actual footprint.
Therefore, we assign an Approximate rating. This decision is informed by:
Our goal is always to match the pin location as closely as possible to the real-world context, especially when dealing with unique property features.
Pin accuracy is vital for transit POIs like bus stations. The ideal spot for a pin is directly on the platforms where passengers wait or the area between platforms in stations with multiples (GL 9.6.2).
When evaluating a pin for Approximate Pin Accuracy, we need to look at the entire transit property, which can include parking areas and adjacent spaces, but adhere to the Half ‘n’ Half rule as outlined in GL 9.1.3.1.
It’s crucial to remember that infrastructure like bridges or overpasses should only be considered part of the waiting area if they’re explicitly meant for boarding or waiting.
Query: מרכזית המפרץ (HaMifrats Central)
Result: מרכזית המפרץ, חיפה, ישראל (HaMifrats Central, Haifa, Israel)
Pin: 32.793173, 35.035188
Pin Accuracy: Approximate
The query intent is a central bus station in Haifa, HaMifrats Central. While the pin lands on a bridge associated with the intended station, according to 9.6.2 in GL, for transit POI, the pin should fall on the station’s rooftop or platform or the area between its rooftops or platforms. Since the bridge connecting the station to a nearby mall isn’t part of its platform, the correct rating should be Approximate.
When rating the address accuracy for POIs where users wouldn’t typically expect a complete street address, such as squares, parks, and transit stops, it’s crucial to follow a systematic workflow. First, identify the result type and location intent, referring to sections 2.2 and 2.3 of the GL. Next, research the POI using official resources like websites, social media, and maps or reliable sources like street imagery and user reviews, as outlined in section 6.1 of the GL.
To determine if the POI has an expected address, consult section 8.3.2 of the GL. If a full address is not expected, focus on verifying the minimum required components, typically the locality. If a full address is provided, verify each component against official or reliable sources, referring to section 7.1 of the GL and CSGL_IL.
Consider special cases, such as POIs with official addresses that differ from the result address (section 8.3.2.2 of the GL) or those with no official address (section 8.3.2.3 of the GL). Check for additional issues like repeated POI names or language/script issues, as described in sections 7.5 and 7.3 of the GL.
Finally, apply the appropriate rating: Correct, Correct with Formatting Issue, Incorrect (selecting specific checkboxes), or Can’t Verify.
Special considerations for Israel: When addressing accuracy, if an address isn’t listed in the official sources outlined in section 3 but appears in any official source, rate it normally (CSGL_IL 6.2.1). If an address is absent from both mentioned sources or unverifiable but visible in recent (last decade) street-level imagery showing clear street names and numbers, use this imagery for verification, given the relative stability of street names. If no reliable recent imagery exists but an address is claimed on a business’s official site, this can suffice for verification. However, if no research validates the address, you must mark it as Incorrect – Address does not exist.
For small localities without detailed street imagery and only one postcode, it’s tough to pinpoint specific addresses or streets. In such cases, assigning an Address Accuracy – Can’t Verify rating is appropriate, acknowledging the limitations in verifying exact locations in these areas.
Example 1 – Name of POI appears in Address – Incorrect – Other Issue:
,Azrieli Mall Tel Aviv) קניון עזריאלי תל-אביב, דרך מנחם בגין 132, תל אביב – יפו :Result Address
Menachem Begin Road 132, Tel Aviv-Yafo)
Correct Address: דרך מנחם בגין 132, תל אביב – יפו (Menachem Begin Road 132, Tel Aviv- Yafo)
Issue: The resulting address includes the name of the business/POI (“-קניון עזריאלי תל אביב”) within the address details.
Explanation: While including the business/POI name might seem like additional information, it is not considered a component of the address and can be redundant and unnecessary.
Redundancy: The business/POI name is already displayed prominently as the result title. Repeating it in the address details adds no additional value regarding location information.
Guidelines Reference: According to section 7.5: Other Issue of the GL, including the POI name within the address details is considered an “Other Issue” and should be rated as Incorrect.
Example 2 – Locality appears twice in address – Incorrect – Other Issue:
Result Address: טשרניחובסקי 32, חיפה, חיפה (Tchernichovsky 32, Haifa, Haifa)
Correct Address: טשרניחובסקי 32, חיפה (Tchernichovsky 32, Haifa)
Issue: The resulting address includes the locality (“חיפה”) twice.
Explanation: While including the locality once is essential for identifying the location, repeating it serves no additional purpose and can be confusing and unnecessary.
Guidelines Reference: According to section 7.5, Other Issue of the GL, including duplicate address components within the result name, is considered an “Other Issue” and should be rated as Incorrect.
When rating the relevance of results for ambiguous queries, where the user’s intent may not be immediately clear, follow these steps to ensure accuracy and consistency:
First, identify the result type (business/POI or address) as per section 2.2: Result Types of the GL. Next, understand the location intent by determining if it is explicitly stated in the query or implicitly derived from the user’s location and viewport (refer to GL section 2.3: Location Intent).
To comprehend the possible interpretations of the query, research it using search engines and your local knowledge. Investigate the result using official resources and reliable sources to confirm its details and prominence, as outlined in GL section 6.1: Research Expectations.
When rating relevance, identify the query-result connection based on user and location intent. Determine if the connection is clear and easily understandable by the user (see GL section 5.1: Query-Result Connection for different connection types). Classify the user intent type as primary, secondary, or unlikely (refer to GL section 5.2: Satisfying User Intent).
Consider the result’s prominence and whether it can be promoted to a higher intent type (GL section 5.3: Prominence). Evaluate the distance between the result and the user’s location or viewport and determine if the result should be demoted due to distance (GL section 5.4: Distance and related sections).
Apply the appropriate rating: Navigational, Excellent, Good, Acceptable, or Bad. For ratings of Good or below, select the relevant checkbox(es) to indicate the reason(s) for demotion (User Intent and Distance/Prominence).
for Landmarks and Natural Features
Following a structured workflow is crucial when assessing the Name accuracy of landmarks and natural features. Here’s a concise guide to ensure precision in your ratings:
Special considerations for Israel: Regarding address and business name verifications in Israel, two key official sources are used: the Israeli Post Service and the Israeli Government Map (CSGL_IL 3). For Address Accuracy, if any source aligns with the result, the address is deemed correct.
Regarding postal codes, remember Israel shifted from 5-digit to 7-digit codes in 2013 (CSGL_IL 3.1). A postal code isn’t mandatory for an address, but if present, it should be the complete 7-digit number. Different entrances might have unique codes; the provided code should correspond to the specific entrance or building. Wrong postal code usage affects the Address Accuracy rating.
Diacritics are crucial in Hebrew, impacting Name Accuracy in businesses and POIs. Missing or incorrect diacritics in names or address components can lead to a Partially Correct or Incorrect—Other Issue rating, respectively (CSGL_IL 3.2).
Street name variations also matter, especially the correct use of street types (e.g., boulevard, road), which are essential except for ‘רחוב’ (street), which can be optional. Address Accuracy should be downgraded if street types don’t match the official records or essential elements are omitted (CSGL_IL 3.3). For roads and highways with numerical names, including the term ‘road’ or ‘highway’ is necessary to avoid incorrect ratings.
Example 1 – Incorrect Classification:
Result Name: נחל צין
Classification: הר (Mountain)
Name Accuracy: Incorrect
Explanation: The result “נחל צי ן” (Tzin River) refers to a specific stream in the Negev desert in Israel. The result’s name is correct. However, the classification assigned to the result is incorrect.
Incorrect Classification: The result is classified as “הר” (Mountain), which is wrong. It is a stream, not a mountain.
Guidelines Reference: According to section 6.3.2: Incorrect Classification of the GL, when the classification is wrong or misleading, the final Name Accuracy rating is Incorrect, regardless of the name’s correctness.
Example 2 – Partially Correct Classification:
Result Name: Taizu Restaurant (טאיזו)
Classification: מטבח אסייתי (Asian Cuisine)
Name Accuracy: Partially Correct
Explanation: The Taizu Restaurant is listed with the correct name and identified as an Asian cuisine spot, matching the details on its official website. But, since it shows the name in Hebrew and English and we wouldn’t typically expect English for a local business name in Israel, its accuracy is Partially Correct according to section 3.4 in CSGL_IL.