Sure; you could use compressed public-domain vector-based street data, and you could render map images on-the-fly based on the data. And, if you could find enough free data, or if you had a non-trivial chunk of cash to buy it, you could even calculate route directions on-the-fly, automatically adjusting as you drive off course. This is generally what TomTom or expensive in-car navigation systems do.

Unfortunately, it would run slower than molasses on a Nokia 770, or it would look considerably uglier than what Google Maps provides (admit it - TomTom's "maps" are ugly). There is no way that Maemo Mapper could generate images as pretty and readable as those which Google Maps provides without expending an unreasonable (and likely unusable) number of CPU cycles, especially without hardware floating point operations. Hell, even Google Maps admits its complex to generate aesthetically pleasing maps on-the-fly; that's why they pre-render the maps and store the PNGs on network drives. That's what made their web site so much slicker than MapQuest or Expedia. It would be near impossible to provide operation as smooth as Google Maps if you were generating maps on-the-fly from vector data.

Furthermore, the design for a "Vectorized Maemo Mapper" would be so completely different that, if such an effort were engaged upon by some entrepreneurial lads with more time on their hands than I have, I would suggest that it create a product separate from Maemo Mapper, so as not to unnecessarily increase the memory requirements of the application for those who prefer raster maps to vector maps. It could take the form of a #include-controlled separate build, or as a minimal web server that could serve tiles based on vector data.

In any case, I'm happy with raster images and do not have any motivation to sacrifice anti-aliased beauty by trying to modify Maemo Mapper to support vector data. Maemo Mapper is GPL, though, so feel free to contribute if you wish.