This article describes PlaceBrowser, a PDA based application that allows the user of the application to navigate around an area of geographical interest, such as a city, using a zoomable, panable hierarchy of aerial images, in a fashion similar to Google Maps. The novel aspect to the work is that an area of precise interest within the map can be pin-pointed by the user by directly dragging out a rectangular area on the map. This forms the source to a spatial search that returns landmarks that are then used to trigger a Web based query. The results of this query are displayed to the user. The net effect is that, in response to dragging out a rectangular area, web pages that are relevant to this area but have not been explicitly geo-spatially tagged with metadata (longitude,latitude) are shown to the user

Arter, David

Bainbridge, David

Jones, Matt

English

Research Commons@Waikato

Working Paper SeriesISSN 1177-777XA map-based Place-browser for a PDADavid Bainbridge & Matt Jones & David ArterWorking Paper: 07/2007October 24, 2007c©David Bainbridge & Matt Jones & David ArterDepartment of Computer ScienceThe University of WaikatoPrivate Bag 3105Hamilton, New ZealandA map-based Place-browser for a PDADavid BainbridgeDepartment of Computer ScienceUniversity of WaikatoHamilton, NZdavidb@cs.waikato.ac.nzMatt Jones, David ArterDepartment of Computer ScienceUniversity of SwanseaSwansea, UKm.jones@swan.ac.uk,davea@sucs.orgABSTRACTThis article describes PlaceBrowser, a PDA based appli-cation that allows the user of the application to navigatearound an area of geographical interest, such as a city, us-ing a zoomable, panable hierarchy of aerial images, in afashion similar to Google Maps. The novel aspect to thework is that an area of precise interest within the map canbe pin-pointed by the user by directly dragging out a rect-angular area on the map. This forms the source to a spatialsearch that returns landmarks that are then used to triggera Web based query. The results of this query are displayedto the user. The net effect is that, in response to drag-ging out a retangular area, web pages that are relevent tothis area but have not been explicitly geo-spatially taggedwith metadata (longitigude,latitude) are shown to the user.Keywords: Mobile Searching, Context Aware, SpatialSearch.1 IntroductionThis report describes the work undertaken in developing amap-based browser we have called the PlaceBrowser. Thework fits in to a larger programme of work currently un-derway at the Future Interaction Lab (FITLab) at the Uni-versity of Swansea that is studying location/context awareweb searching. The work presented here builds on andmodifies that of the Questions Not Answers (QnA) sys-tem by Jones et al. [2].QnA uses a GPS-enabled PDA upon which is dis-played an aerial map of the area the user is in, augmentedover time with queries that other people have made whenthey were situated in the same area. Displayed queriesare position on the map at the x,y coordinate (longi-tude,latitude) where the query was instigated. Using thePDA’s stylus, if the user clicks on one of the displayedquery terms displayed on the map then a web search us-Permission to make digital or hard copies of all or part of thiswork for personal or classroom use is granted without fee pro-vided that copies are not made or distributed for profit or com-mercial advantage and that copies bear this notice and the fullcitation on the first page.c©2007 University of Waikatoing that term is initiated and the shown the ranked listof resulting matching documents. By seeding querieswith automatically generated geo-spatially tagged “land-marks,” our work considers a different dimension to loca-tion/context web searching.The structure of the paper is as follows. First we gothrough a worked example that illustrates the main capa-bilities of the implemented system. Next the context tothe work is provided, which includes background detailsto related work and the key data-structure used. Imple-mentation details are then provided before we concludewith a summary of the work and future plans, which in-cludes a field trial of the system with two other mobilesearching prototypes.2 Worked ExampleIn PlaceBrowser, an aerial map is provided (a` laGoogleMaps) with panning and zooming capabilities. Notextual details are shown, however, other than street nameinformation that comes as part of the rasterised hybridaerial view. The user spatially navigates around themap and when they see an area of interest, they drawa rectangular box enclosing it. This triggers a websearch where behind the scenes GIS-encoded data aboutstreet/placenames is used for query terms, and the rankedresults displayed to the user.Figure 1 shows a sequence of still shots taken from avideo of a typical user session.1 First the user launches theapplication, which is located in the top-level applicationsmenu as seen through Figures 1(a)–(c). After a short delayPlaceBrowser open up with an aerial view, in this caseSwansea city centre (downtown) although it can equallybe tied to the GPS position of the user—the receiver canbe see back in Figure 1(a)—although startup takes longeras it needs to lock on to satellite transmissions.At the bottom of the PlaceBrowser application aresome overlay buttons. Two on the left, and two on theright. The left-most ones control pan and spatial search,and the right-most control zooming in and out. Be defaultthe application starts in pan mode, and in Figure 1(e) theuser is dragging the stylus on the map to change the areadisplayed. In Figure 1(f) they are changing the mode tospatial search. Now when they drag the stylus across the1The original video footage can be viewed throughwww.nzdl.org/epsrc-fellow-2007/pda.(a) PDA running Windows Mobile (b) Selecting PlaceBrowser application (c) Launching Placebrowser(d) Initial map view (e) Panning map (f) Selecting spatial search(g) Dragging rectangular area (h) Search results (i) Selecting top hit(j) Swansea clothing for men (k) Closing the browser (l) Returning to map viewFigure 1: Snapshot sequence of using the PlaceBrowser.map, as they are doing in Figure 1(g), instead of panning arectangular outline is drawn to signify the area that a spa-tial search will be based on. The user continues adjustingthe position of the stylus until they are satisfied with thearea outlined.Upon lifting the stylus away from the screen, thesearch is initiated. Using an Internet connected (e.g. wire-less), after a short delay the results of the query are shown.Figure 1(h) shows the result page for the spatial query(centred in our example on the large roofed building po-sition in the middle of the screen) and Figure 1(j) thepage that results from choosing the top match, a pageabout Swansea Clothing For Men, which is indeed a storehoused in the building in question. Finally, in Figure 1(k)the user has clicked on the browser close button at the bot-tom of the screen to return back to the map view.3 BackgroundLocation/Context-aware browsing is an emerging field inwhich Jones, along with other colleagues at the FITLab,are making significant progress.At the core of the PlaceBrowser work is a spatialsearch capability. KD-Trees are an efficient, well knownand much studied technique for this [1, 3] which—unlikeGIS-enhanced features for relational database systemssuch as PostGIS2—meets our requirement of somethingthat can be performed locally on the mobile device. Us-ing KD-Trees, construction of this spatial data-structure isO(N logN) for N points. Worst case for spatial search-ing is O(N logN) which corresponds to the user drawinga rectangle that entire map. This would require a certainamount of zooming out in the PlaceBrowser application toachieve this, and so is highly unlikely in our application.Best case is O(logN) with the majority of typical search-ing only slightly greater than this on average. For thesereasons KD-Tree was chosen as as a basis for this work.Two GIS-labelled dataset were experimented with:postcodes (zip-code in US parlance) and streetnames—the latter being fairly straightforward to derive once theGIS-labelled postcode were obtained. Unfortunately GIS-labelled postcodes for the Swansea area (or any UK cityfor that matter) were not readily available and some effortwas expended deriving a suitable solution. In the first in-stance, a sweep of gazetteers in the public domain yieldednothing of any use. Further investigation uncovered themain impediment: despite the Ordnance Survey and theRoyal Mail being state owned entities, government direc-tives dictate that they should be profitably, and this in turnhas led to them only making such data available commer-cially. In this regard, the UK is not as enlightened as itsUS where legislation ensures that “copyright protection isnot available for any work of the United States Govern-ment” effectively putting it in the public domain.The UK situation is in fact quite perverse:3 when acouncil signs off on a newly named street in their city,they are legally required to provide detailed GIS data totwo state-owned entities: Ordnance Survey and the Royal2See postgis.refractions.net for more details.3See www.guardian.co.uk/technology/2006/nov/16/ epub-lic.guardianweeklytechnologysection for more details.Mail. These organisations assimilated this data into theirwider dataset, which is by all accounts, a fairly automatedprocess. Next comes the twist: should a council wish toprovide a map-based web service (say establish the closestbus stops to your home, based on street address or post-code information) the council has to pay the state agenciesfor access to data that, for the main part, they created! Andit is not just a question of a modest one-off annual fee—the cost is based on the number of requests to the centraldatabase, which of course if directly proportional to howoften people use the council’s website. The royal mailis making nearly 2M pounds profit per year. Trying torectify the situation has resulted in a mess that has snow-balled over the last five years with ever-spiralling costs tothe UK tax-payer, and led to the Free our Data campaignspearheaded by the Guardian newspaper and other con-cerned groups. At the time of writing (August 2007) theissue remains unresolved.A solution to acquire the necessary GIS informationwas devised using information available through map-based web sites such as GoogleMaps and StreetMap. De-tails of this along with other aspects of the implementationare given in the next section.4 ImplementationDevelopment work was carried out in C# using VisualStudio for the Pocket PC. The PDA used was a GPS-enhanced Dell Axim X51v running a 624 MHz processorwith 64 Mbytes of main memory, and 190 MBytes storagecapacity; a further 512 Mbytes was available on the GSPSD card. Its screen resolution was 640 X 480 and an In-ternet connection (through a host-machine) was availableusing either bluetooth or the PDA’s docking cradle. Wire-less was also available on the device, but the environmentthe PDA was operated in did not permit the device to beconnected.There were two parts to the software written: a batchdriven, command-line program written in Perl that “page-scraped” online map-service sites to develop the necessarygazetteer; and the PlaceBrowser application written in C#that used this gazetteer in combination with map data andthe Internet connection to provide the desired functional-ity. All code is stored in a Subversion repository hostedby Swansea University’s Computer Society.44.1 Gazetteer generationFigure 2 shows the street and postcode gazetteers thatwere developed and experimented with. Perl code waswritten to collate this information. Output is in the XML-based KML (Keyhole Markup Language) format. Key-hole was the development name for what eventually be-came GoogleEarth, and KML was developed to allowusers to exchange map annotations. It is useful for our pur-poses as it is straightforward to parse by our application,with the added bonus that is can be easily displayed visu-4The code can be checked out with the command “svn cohttps://sucs.org/ davea/svn/qna/gazetteer”. Currently there is noanonymous checkout, you’ll need a username and password.Contact Dave Arter davea@sucs.org for this.(a)(b)Figure 2: Gazetteer generated location information: (a) Streetname (b) Postcode.ally through the GoogleEarth applications—for checkingpurposes and the generation of figures for papers writtenabout the work! For further information on KML see theWikipedia entry.5The Perl code was written using the coding practisesof the Greenstone digital library project, of which the prin-ciple author of this paper is a key member. Document in-gest is a significant portion of the processing work donein forming a digital library, and in Greenstone this stageis implemented in Perl. Multimedia documents, includingmaps, is the focus on on-going work in the Greenstoneproject, and there is the potential for the software devel-oped for the PlaceBrowser to be further developed throughthis connection.Having sourced the setup file (setup.bash), which aug-ments the user’s environment so the gazetteer generatingsoftware can be run, a six step process produces the re-quired KML files:1. Sample a rectangular grid (longitude,latitude) over achosen area (e.g. Swansea) using street-maps.co.ukto generate a set of webpages about each samplepoint; save this data locally.2. Page-scrape Street-Maps’ downloaded pages forpostcode data, and store in a flat-file database.3. Use street-maps.co.uk again to refine precise (longi-tude,latitude) of postcode, as the chosen co-ordinatein Step (1) is unlikely to be the precise location ofa defined postcode. Inside the web pages initiallydownloaded from the site is a table entry that stateswhat the nearest postcode to this location is. Thelongitude and latitude position for this item is what isused to query Street-Maps for a second time. Againa local copy of the generated page is saved locally.4. Page-scrape Street-Maps’ pages for the true positionof postcodes (longitude,latitude), and save this infor-mation in a separate flat-file database.5. Use Google Maps to generate pages with street nameinformation in it per postcode in the flat-file database.This is done by asking Google to generate directionfrom getting from point A to point B. The points canbe given as postcodes. Make both the start and finishpoints the same, and save the generated web pagelocally to disk.6. Page-scrape Google Maps’ pages for street name (theonly street mentioned in the “directions” section ofthe page).Gnu’s DataBase Management library (GDBM) waschosen as the flat-file database system used. One of themodules to Perl (GDBM File) allows you to map (usingthe keyword tie) a GDBM database to an instance ofthe language’s built-in associative array data-type. Forthe purposes of programming, it is as if you have thedata resident in memory, accessed by string-index. TheGDBM File Perl module takes care of mapping the in-memory data-structure to the database format.5http://en.wikipedia.org/wiki/Keyhole Markup LanguageDespite the street name gazetteer being visually moreappealing than its postcode counterpart (Figure 2) andtherefore to more naturally convey better information forinitiating web searches once a user has dragged out a rect-angular region, trials showed that it did not yield as high aprecision as postcodes; consequently the postcode versionof the gazetteer was used in the final version.4.2 PDA applicationImplementation of the placebrowser application wasstraightforward overall, given the existing functionality ofthe Question not Answers system that allowed for panningand zooming a tiled hieararchy of aerial images. The cod-ing to include the necessary user interaction sought forthe placebrowser application was accomplished throughinherience—no structural changes to the existing code-base were made—the key work being the inclusion of arubber-banding feature to draw the area for the spatialsearch. Double buffering was used to make this flickerfree.The other key component to the implmentation wasreading in the gazetteer to build the KD-tree. StandardN˙ET classes for XML parsing were used to read in theKML file, and the necessary 2-dimensional tree built, al-ternating between x− and y-dimensions as a node’s keyat successive layers of the tree. Spatial search (also calledorthogonal range in some fields) is a standard applicationof recusrive programming.One technical hitch encountered during the pro-grammning centred on the web browser form supplied bythe .Net framework. As far as we could deduce, construct-ing a URL with CGI symbols such as ? and & caused thepanel to fail to load the stipulated URL, instead return-ing an error message. Different search engines were tri-alled, but to no avail. Careful consideration was given tothe problem: different methods for encoding these spe-cial characters were utilized, however the problem re-mained. If the constructed URL was instead displayedon the screen, and then this was manually copy and pastedinto the PDA’s provied web browser (IE) then the searchwas performed correctly, and the appropriate result pagereturned. The closed source nature of the .Net frameworkwas a considerable frustration here. Further effort wasspent looking for descriptions (and solutions) to the prob-lem on the web, but this turned up nothing useful. It isthe conclusion of the authors that the problem is a bug inthe Microsoft Compact Framework’s .Net form for webdisplay.A workaround was developed to allow the project toproceed. This was:1. opening a URL connection2. downloading the file3. modifying the downloaded HTML so relative linkswork correctly4. instructing the .Net browser form to open up the localmodified file instead.Fixing relative links was done using a regular expres-sion that matched and then replaced particular HTML at-tributes. This could have equally been done with the addi-tion of a <base> tag instead.5 ConclusionThis technical report has described the work undertaken indeveloping PlaceBrowser, a PDA based application thatallows a user to pan and zoom a geographic area rep-resented through a series of aerial photos. The city ofSwansea in Wales was chosen as the sample location. Us-ing the application, the user can trigger a spatial search bydirectly drawing on the screen a rectangular area that isof interest to them. Based on “landmarks” represented asa KD-tree, those points falling in the area of interest areused as query terms to an web search engine. Throughempirical experimentation we found postcodes of the areato work well. These postcodes, along with their longi-tude and latitude positions were collated through a pro-cess of sampling web pages from street-maps.co.uk andmaps.google.com.References[1] J. L Bentley. Multidimensional binary search treesused for associative searching. Communications ofthe ACM, 18(9):509–517, September 1975.[2] Matt Jones, George Buchanan, Richard Harper, andPierre-Louis Xech. Questions not answers: a novelmobile search technique. In CHI ’07: Proceedingsof the SIGCHI conference on Human factors in com-puting systems, pages 155–158, New York, NY, USA,2007. ACM Press. ISBN 978-1-59593-593-9. doi:http://doi.acm.org/10.1145/1240624.1240648.[3] H. Samet. The Design and Analysis of Spatial DataStructures. Addison-Wesley, Reading, MA, 1990.

A map-based place-browser for a PDA

Abstract

Similar works

Full text

Available Versions

Research Commons@Waikato

Name not available