July 25, 2006
The whole world has gone map crazy, or so it seems. Even those of us
who habitually confuse longitude and latitude have turned geo gaga. Is
it something in the water? In fact, the typical spatial convert is
largely compos mentis: not mad about maps, so much, but rather
sensibly interested in information (conveyed primarily via text, images
and location) that relates to him. My own company, Schmap, is focused on the dynamic
integration of information with maps...
Consider this common scenario. I have a map and some information about
places – let's say Italian restaurants - that could be shown on this
map. I have an article talking about these restaurants, reviews and
photos for each, plus a directory of restaurant addresses. The
challenge here is that, even in this simplest of cases, there are many
ways that a reader might want to browse and use this information.

Some readers will find the article interesting, yet only certain
restaurants will catch the eye sufficiently for them to want to see a
detailed review. Some readers are more spatially inclined – they might
prefer to browse the map, spotting restaurants that merit
investigation. Others would like to view pictures and only read further
should one of these suggest an ambience conducive to the type of dining
experience they're after.
Another class of readers is pressed for time and would like to take a
quick virtual tour of ‘must visit' eateries. Still others are
data-driven and would want to see the restaurants listed, perhaps in
order of price or Michelin rating. Then there are those interested only
in restaurants that match certain criteria, such as offering disabled
access or accepting a particular credit card.
One reader wants to email restaurant details to a friend; another needs
driving directions; a helpful type wants to tell the writer he's made a
mistake; a fourth wants to bookmark several restaurants for later
reference. Another reader wants to print reviews and a map for a
handful of restaurants in his neighborhood; an inquisitive one wants to
research further (see what the dining public has to say on a website,
perhaps); another wants to copy the addresses of three restaurants to
her PDA. One hungry reader simply wants to head straight to the closest
bistro and chow on down.
And so it goes on: one simple set of data, with countless ways to
browse and use it. How to manage and present this information in a
fashion that pleases all these folks is a basic question that drove
much of the development behind Schmap (as in ‘map, schmap' or ‘any
schmuck can schmap').

Our first stab at integration is called the Schmap Player. The
basic concept is a small desktop app, one that stores map data
client-side and uses the client processor to maximize performance.
Specifically, we make the maps ‘light' (using a vector format developed
for this purpose), so that a whole city can be comfortably cached in
RAM, instantly viewable at any level of detail. Together with the
client-side caching and indexing of images, text and addresses, this
allows us not only to integrate data (as a website might do), but to
mesh it dynamically in a variety of ways…
When I'm reading an article, for instance, I mouse over a place name,
and an overview map shows me in real time where this is (a click takes
me to a detailed map and another back to the text). Mousing over a
place name in the text - or an icon on the map - is sufficient to
display a review, plus a slideshow of photos. A list of places –
museums, say - updates automatically as I pan around the map. Moving
closer, new layers of detail come naturally and dynamically into view
(rather than jumping into frame at the next available zoom stop); as I
mouse over a road name, it automatically expands to improve readability.
Dynamic meshing aside, opting for a client-side component opens up a
number of interesting possibilities, many of which would prove clumsy
or unachievable with a browser/server solution. These include advanced
custom print, local storage and editing of points of interest (for
reference offline, and perhaps transfer to/from other applications),
and the chance to collate or author map-related data in a controlled
environment. The client-side app can then integrate seamlessly - via an
Internet browser - with a vast and growing body of geospatial data on
the Web, with limitless potential for useful interaction…
In Schmap's case, much of this functionality and integration is
development in progress. Right now, we demonstrate the basic
integration (maps, text, pictures, directory listings and some Internet
links) with a series of free,
downloadable travel guides, for destinations throughout the United
States and Europe (Canada, Australia and New Zealand available soon).
We've released 84 such Schmap Guides since launch in March and have
scheduled a total 200 by the year's end.

Later this month, we'll incorporate Schmap Geolink. Instead of mashing
information from one or more sources onto a map, Schmap Geolink treats
the map as a portal to specialized information for the same map, and
the place as a portal to other sources of information about the same
place. As an example, browsing a map of Greenwich Village (in Lower
Manhattan), Schmap Geolink might let me jump to see house prices for
that same map at Zillow.com, or current weather for the neighborhood at
Weatherbonk.com, or search for a drugstore, again on the same map, with
Google Local. Likewise, when looking at a specific place - the Empire
State Building, for instance - I might jump to read more at Wikipedia,
to view photos of this landmark at Flickr, or to get driving directions
(say, at Mapquest).
In the fall, we'll unveil Schmap Local (with some twists of its own on
the accessibility of local search to the average schmapper), then
follow this with Schmap 2.0, opening the technology for users to author
and share their own collections of places.
For now, please enjoy one of our Schmap Guides – and if you have any
Schmap-related thoughts, please
drop me a line.
|
Your Comments Post a comment All comments provided in this section are those of the individual who has created the post. These are not the opinions of Directions Media, its editors, staff or owners unless otherwise noted. Directions Media retains the right to edit or delete any comments posted herein.
|
|
||||||
| I keep reading about new mapping technology for the masses but seldom see any mention of the quality problems associated with the spatial data that are being utilized. It appears to me that only too often any problems associated with locational accuracy or the temporal relevance of the data are ignored. The attributes associated with the spatial entities are also pose a problem. Who defines them? Are they current? Mapping technology and good spatial data are two sides of the same coin! |
||||||
|
||||||
| Well aimed point. I think people in general intuitively believe what maps represent, which can be problematic. But for the general purpose maps like these, the basemap (roads, water, parks) are standardized data (US Census Bureau, or private company like Thomas Bros.) and the location and attributes of stores and restaraunts such as the examples are likely third part commerical data providers. So, even though these apps may not cite the data source, I think they are more or less accurate for their intended use, with the understanding (I am assuming) that there may be errors, just like the phone book contains errors. I also assume people will not use these maps to navigate to a great precision. Useful way to slim down portable access to geo and commercial data. I like it. Chris |
||||||

