Project

General

Profile

Bug #2998

Place Name feature on ONEMercury page does not appear to be working

Added by Bruce Wilson almost 12 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Skye Roseboom
Category:
d1_mercury
Start date:
2012-06-20
Due date:
% Done:

100%

Milestone:
CCI-1.0.2
Product Version:
*
Story Points:
Sprint:

Description

On https://cn.dataone.org/onemercury, place any text in the "Place Name" field below the geographic search. I tried a variety of states, cities, and countries. Click on "show on map" next to this field. I saw no apparent traffic to the server (no refresh action) and no apparent change to the search screen. I tried this in both Chrome 19.0.1084.56 and Firefox 13.0.1 on a Mac running 10.7.4. From an end user perspective, this field and button don't appear to be doing anything.

redmine2998.patch Magnifier (857 Bytes) Skye Roseboom, 2012-06-21 16:11

redmine2998-part2.patch Magnifier (2.08 KB) Skye Roseboom, 2012-06-22 18:05

History

#1 Updated by Bruce Wilson almost 12 years ago

This appears to be both a documentation and an interface issue. The place name is getting passed along to the query, but isn't showing up on the map. And the meaning of Place Name in the query isn't clear. I'm guessing this is matching a metadata field, but it's not clear.

#2 Updated by Skye Roseboom almost 12 years ago

I have fixed the broken javascript so the Name Place resolution succeeds and draws a bounding box around the 'place'. Issue was introduced with the update from google maps api v2 to v3. I have placed this fix on ONEMercury trunk and will discuss with Dave regarding placing this in a future release - patch or minor release.

However there may need to be larger discussion regarding the use of this search field:

I agree, the intention of this field is a bit hard to understand. This field generates queries that search both the 'placekey' field in the solr index as well as matching the bounding box coordinates (generated when user clicks 'view on map'). For best results this query may need to change to an OR boolean logic operator rather than AND. So results that have the placekey or overlap the bounding box coordinates (generated by the place name UI field) are matched. I think this would be more transparent to the user - serve as a more general purpose search. However, I do not know how difficult or easy this change would be in the mercury search logic.

#3 Updated by Skye Roseboom almost 12 years ago

attaching patch file with js fix.

#4 Updated by Skye Roseboom almost 12 years ago

After speaking with Ranjeet - we agreed to remove the 'placekey' value as part of the query when using the 'place name' search ui controls. Placekey is specific to certain metadata while lat/long coordinates are most common.

So the place name search ui controls will now function like the place name drop down controls. It will draw the bounding box and set the bounding box coordinates into the query. Placekey field will not be part of the query.

#5 Updated by Skye Roseboom almost 12 years ago

  • Assignee changed from Giri Palanisamy to Skye Roseboom
  • Target version set to Sprint-2012.25-Block.4.1
  • Milestone changed from CCI-1.0.0 to CCI-1.0.2

Assigning this issue to myself so I can track resolution and placement in patch release.

#6 Updated by Skye Roseboom almost 12 years ago

Attaching patch file that represents the changes to default.js and searchform.html to remove 'placekey' from being set and used in the query string generated from the mercury search UI.

Geocoder.js is still having issues with the bound() callback function. point.lng() and point.lat() are being called but are not functions. Place Name feature works for US states and countries but doesn't want to work for cities names or Canadian provinces.

#7 Updated by Bruce Wilson almost 12 years ago

  • Status changed from New to In Progress

#8 Updated by Skye Roseboom almost 12 years ago

Copied to 1.0.0 branch for 1.0.2 release.

#9 Updated by Skye Roseboom over 11 years ago

  • Position set to 1
  • Target version changed from Sprint-2012.25-Block.4.1 to Sprint-2012.27-Block.4.2
  • Position changed from 1 to 470

#10 Updated by Skye Roseboom over 11 years ago

  • Position deleted (473)
  • Position set to 17

#11 Updated by Skye Roseboom over 11 years ago

  • Status changed from In Progress to Closed

tested with 1.0.2 patch release. Works on US states and countries names.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)