Notes from the project meeting of July 21st


This meeting marked the end of WP1 (Configuration of Mobile Mapping Technologies) and the start of WP2 (Defining the User Experience)  These are the notes that I took from the meeting.

Report on WP1
We have a working demo.  It can link GPS to the historical maps from EDINA and also Google Maps.  We are using Google Maps to control the positioning and zoom, which we then use to select the appropriate parts of the historical maps.  There is some work needed to map the Google coordinates to the EDINA coordinates.

The demo uses web APIs for maximum portability, including the W3C geolocation Javascript API which runs on the (very) latest versions of Safari, Chrome and Firefox.

There may be a legal limitation with Google maps when we eventually add authentication to control access to the licensed EDINA service and to our WalkThruT server.  We could use Open Street Map instead.  Also, we are not allowed to change the projection of the Google maps; we would have to convert our maps into that projection.

Tasks to be completed
This is just a prototype.  Many things need to be improved.  To pick a small example, flipping from portrait to landscape doesn’t work.

We need to fix inaccuracies in the mapping between projections, from the one used by Google (which favours North America) to the British National Grid.  Petra and Peter will discuss this with EDINA this afternoon.  Tim said that EDINA could put more conversion support in the map server, e.g. TileCache can hold pre-computed projections at different fixed zoom levels.

Questions to explore in WP2
We need to explore whether we can provide our own navigation, e.g. via the Open Layers Javascript library.  OpenLayers is designed for web sites so may need some modification to work with touch screens.  Writing all this from scratch might be time consuming, which would be a distraction from getting users up and running.

The ECA team should give feedback on the user interface, e.g how to switch between maps, whether you can overlay maps, etc.  This is not a formal usability analysis, just informal feedback.

When switching between maps, we need to be aware that different maps are only available at different scales.

How should the landmarks and routes be displayed to the users?  What makes most sense?  How much information should be visible?  It would seem desirable to keep the plain image as one view.

What do we want to show when a user reaches the edge of the historical map?  Currently the server returns white space (which is its correct behaviour).  The map data doesn’t include an outline of where the map data ends.

Different towns were mapped in different times and distances.  E.g moving from Edinburgh to Musselburgh might be displayed in different times or scales.  One idea is that when we zoom out, the display just shows hatched areas where map data is available, without trying to convey more detail.

It’s worth noting the dates we have for the historical maps is the publication date, which may be up to 20 years after the survey date.

Do we want our information links to include links to paintings of the particular area, as well as text information?

Immediate actions

  • Petra and Peter to discuss projections with EDINA.
  • Peter to set up VPN access for Chris, Ian and Karlyn so that they can test.
  • Chris, Karlyn, Peter and Petra to meet again this week and twice next week.
  • Dave to put meeting minutes on blog.
  • Dave to arrange the purchase of the Mac mini.

,

  1. No comments yet.
(will not be published)
  1. No trackbacks yet.