Ticket #156 (accepted enhancement)

Opened 6 months ago

Last modified 2 weeks ago

Geo-searching should place marker

Reported by: sbenthall Owned by: sbenthall
Priority: major Milestone: 2.0 Future
Component: Almanac (JS) Keywords:
Cc: Total Hours: 0.0
Estimated Hours: 0

Description (last modified by sbenthall) (diff)

Interaction design feedback from Phil:

When the extent of a map is very wide, having geo-searching center the map on a location doesn't really focus the map on a place.

This is a problem especially in cases like when somebody is creating a new almanac. The initial extent covers the entire US. Looking up a new place (say, in the northeast) just makes the map move without giving any real indication of where the place is.

In a design discussion, we determined that the best way to do this would be to:
- zoom in on the location searched for
- place a marker on the spot.

To clear the marker, there should be a clear link next to the geo-search box.

Change History

Changed 6 months ago by sbenthall

  • description modified (diff)
  • summary changed from Geo-searching at wide extent doesn't really focus on location to Geo-searching should zoom and place marker

Changed 6 months ago by sbenthall

  • owner changed from tschaub to sbenthall
  • status changed from new to accepted
  • milestone changed from 1.0 Stable Release to 0.8 Working Site

Changed 6 months ago by sbenthall

  • priority changed from major to greatergood

General OL appeal, I think.

Changed 6 months ago by sbenthall

The Google geocoder doesn't give any information about the precision of the result. But Yahoo's geocoding API does. Doing this right will probaly require a Yahoo geocoding control in OpenLayers.

see geoCodeAddress in http://developer.yahoo.com/maps/ajax/V3.8/index.html

Changed 6 months ago by sbenthall

Looks like the response from the API doesn't have the precision level included, whereas Yahoo's REST api does. Using the REST API requires proxying the server though.

http://developer.yahoo.com/maps/rest/V1/geocode.html

Changed 6 months ago by sbenthall

<sbenthall> tschaub: I forget--we don't have any sort of proxying already set up for the almanac, do we?
<tschaub> nope, we don't
<sbenthall> tschaub: so that would require a lot more backend setup, I'm guessing?
<tschaub> well, it shouldn't - just a dumb proxy
<tschaub> depends what else we want to proxy
<tschaub> nginx could probably handle it if it was just yahoo
<tschaub> not hard to drop a view into the grok app that is a proxy (though I'm sure there are reasons not to do that)
<tschaub> third alt is to set up a proxy script next to the almanac
<tschaub> it might not be a bad idea to set up something in the almanac app
<tschaub> a geocode view
<tschaub> then we could switch services (always a hypothetical possibility)
<tschaub> as long as we agreed on the response structure

Changed 6 months ago by sbenthall

The precision-based zooming is all done now.

There is no marker yet.

Changed 6 months ago by sbenthall

  • priority changed from greatergood to major

Changed 6 months ago by sbenthall

  • summary changed from Geo-searching should zoom and place marker to Geo-searching should place marker
  • milestone changed from 0.8 Working Site to 0.9 Improvements

Since the yahoo geocoder for openlayers is now basically done, there is no greater good to be gained from this ticket.

In fact, the marker seems less necessary at this point, since towns appear clearly on the map when the map is zoomed in. I'm pushing this out to 'improvements', as this seems less necessary for the bare-bones working site.

Changed 6 months ago by sbenthall

  • type changed from defect to enhancement

Changed 2 weeks ago by nickyg

  • estimatedhours set to 0
  • milestone changed from 1.1 Improvements to 2.0 Future
Note: See TracTickets for help on using tickets.