I finished most of the basics on nanomaps-droid and got the docs and binaries published out on the project GitHub page. That was more fun than I expected. I had to do a lot of crawling around in the guts of how Android does drawing and layout to design and implement it correctly and that kind of understanding is always worth its weight in gold.

As a public service announcement, another option for maps on Android is OSM Droid.  A lot of people are using it but I had some different things in mind and decided to strike out on my own.

Posted in nanomaps | No Comments »

nanomaps on android April 4th, 2011

I needed a mapping library for android and got frustrated with the options available. So, I put my mapmakers hat back on for a couple of days and produced this: https://github.com/stellaeof/nanomaps-droid

It’s just a no-frills mapping library modeled after nanomaps for JavaScript. Not quite done yet, but it seems to be speedy enough. I spent a fair amount of time today implementing HTTP pipelining which gave a several-fold speed increase in some cases over more naive ways of requesting the tiles.

I can attest that this does get easier the more you do it. This one has taken about two working days from pressing “Create Project” in Eclipse to having something working enough for me to use in the app I’m building.

Posted in nanomaps | No Comments »

How does a non creative person generate map markers?  I pulled out an old tool The Persistence of Vision Ray Tracer to construct some simple 3d scenes and render them to icons.  A little bit of ImageMagick and a Makefile, and I’ve got shiny new map markers:

That’s enough to get me going for now.  I’ll add more colors and other bits later as I need them.

Here’s the GitHub: https://github.com/stellaeof/cgmarkers/tree/master/mapmarkers

I haven’t played with PovRay in almost 20 years.  It’s amazing that its still alive and being improved on.  Back then, rendering something like this on a 12MHz PC would have taken hours, if not all day.  On modern gear, its just a few seconds.

iphone safari scaling weirdness January 27th, 2011

So, the iPhone 4 has a high resolution display: twice that of the original at 640 pixels wide vs 320.  For a variety of reasons, however, the CSS unit affectionately known as px stays fixed with respect to its physical size instead of being an exact representation of the actual dots on the screen.  This is actually all fine and good, because it means that the thing we think of as a “pixel” is still roughly the same size on the mobile device as it is when we see it on our computer monitor, meaning that we can actually read the text as expected without a magnifying glass.  It’s also how the W3C specs were designed, but can be counter-intuitive if you’ve thought for all this time that “px” = dot, which it does not, except on a large majority of the most common display devices: computer monitors.

The iPhone mostly hides all of this from you, presenting all coordinates on the device as being 320px wide vs the full resolution of 640 dots.  This should just be fine.  If you’ve got something higher resolution to display, either fractional units or imagery with a higher density of dots will be rescaled to preserve the distinction.

However, today I noticed one startling thing: If I use the Apple meta tags to force the webpage into native resolution, I get roughly twice the framerate for image manipulation.  Now, you are surely thinking, of course you do because you just removed a rescale operation from the pipeline.  But this is not the case.  The maps library is already rescaling all of the imagery for display and in theory, the iPhone should be just incorporating its own display scale settings into the transformation matrix, resulting in no further work.  However, if I run at native resolution, with image scaling being done by hand in JavaScript and asking the poor iPhone to juggle 4 times as many pixels, I get twice the speed.  The maps library precisely tracks my finger movements with no lag and feels completely native.

To be fair, I do not yet know whether this is actually a rendering issue or a problem with the touch events.  It almost seems like the touch events are being averaged too much when being delivered to an element which has the native 2:1 scale factor applied to it.  I haven’t been able to get precise measurements, but the event stream looks “coarser”, maybe only containing 1:8 the resolution of when running at native scale.

I did verify that using the CSS zoom property produces the same speedup.  For example, zooming a parent element to 50% and then sizing its child to twice normal size creates a high-resolution region on the screen and the events delivered to that region are crisp and precise.

Even though my first experiments with this made me think that the graphics rendering was actually binding up, the zooming and handling very large canvases kind of leads me to believe that there’s plenty of render bandwidth.  If the issue is just related to touch event averaging, then this means that we can get much more precise touch events out of WebKit by targeting a zoomed div.  It really shouldn’t make a difference, but I can imagine some engineers at Apple being faced with this new native zooming and dividing everything, including the internal averager that the touch processor uses, resulting in a touch event stream on hi-res displays in WebKit that is much coarser than it should be.

Stay tuned… with a solution in hand, now I just need to find out why it works.

Some nanomaps Updates December 13th, 2010

I spent some time getting api docs and some other odds and ends done for Nanomaps.  The front page on github (see README) has an example of the “declarative mapping” mode that this library enables.  Basically, you can choose to just add your map content directly to your HTML and then make a simple JavaScript call to turn the container into a map.

Here’s an example of declaratively constructing a map, using CSS to style the markers and copyright.

    #map {
        width: 640px;
        height: 480px;

    #mapcopy {
        z-index: 50;
        position: absolute;
        right: 2px; bottom: 2px;
        text-align: right;
        font-family: sans-serif;
        font-size: 10px;
        cursor: default;
    #mapcopy a:visited {
        color: #00f;

    .poi {
        z-index: 100;
        margin-left: -10px;
        margin-top: -32px;
        display: none;  /* make not displayed by default to avoid startup flicker */

<div id="mymap">
    <img src="images/red-pushpin.png" latitude="39.780533" longitude="-104.988896" />

    <span>Tiles Courtesy of <a href="http://open.mapquest.co.uk/" target="_blank">MapQuest</a> <img width="16" height="16" src="http://developer.mapquest.com/content/osm/mq_logo.png" border="0"></span>
    <br />
    <span>&copy; <a href="http://www.openstreetmap.org/">OpenStreetMap</a> and contributors, <a href="http://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a></span>

    var map=new nanomaps.MapSurface(document.getElementById("mymap"));
    map.attach(new nanomaps.TileLayer({
       tileSrc: "http://otile${modulo:1,2,3}.mqcdn.com/tiles/1.0.0/osm/${level}/${tileX}/${tileY}.png" }));

Working Version of Nanomaps December 7th, 2010

In my previous post, I discussed a little project I started to create a super-small, no frills JavaScript map display library.  Well, it’s mostly working, with still a lot of things to do.  Specifically, here’s what it’s got:

  • Standard desktop gestures for panning and zooming a map (double click, scroll wheel, drag)
  • Standard touch gestures for panning and zooming (only tried on IOS 4.1 so far)
  • Talks to OSM tile servers by default (setup for MapQuest OSM tiles now)
  • Basic zooming to arbitrary resolution.  This still flickers and I know how to really get it right but I wanted to get the event bits in place before experimenting with the core rendering further

What it doesn’t have:

  • IE support.  I’ll add some of this in a separate module.
  • Any testing except on Firefox 3.6/Mac, Safari 5.0.2/Mac and iOS 4.1.
  • Any of the stuff you will find in a full-featured map display library.  This one is structured, however, to let you integrate it easily with your own DOM manipulation and I plan to add a canned jQuery plugin at some point.

The download size of the scripts is 5.1KB (post-GZIP).

So, still a work in progress, but there is a bit more working today than there was.

GitHub: https://github.com/stellaeof/nanomaps

Demo: http://www.laurenzo.org/~stella/nanomaps/demo.html

I’ve got my own reasons for wanting something like this, but drop me a line or watch the GitHub repo if you’re interested in seeing this evolve as well.

Posted in geeky, nanomaps | 1 Comment »

It sure feels that way.  Amazingly, a standard OpenLayers build weighs in excess of 900KB of minified JavaScript.  Granted, GZIP helps a bit, but that is a ton of stuff to ask a poor browser to interpret if you’re goal is just to display a basic map.  After a bit of poking, I found you can build a “lite” version that is only a few hundred KB and strips out most of the features.  And this is when I stopped looking.  Aside from a bloated codebase, it doesn’t really support mobile phones easily (as in limited touch support and extremely bad performance) which is kindof what I was looking to display a map on.

As I was assessing the landscape, I got this incredible sense of deja-vu.  You see, up until recently, I worked for MapQuest.  While there, I wrote a few mapping toolkits or rendering libraries and know a bit about what it takes to build one well.  The MapQuest JavaScript API, while not perfect and suffering from a host of legacy issues such as crazy projection and zoom levels, layers of backwards compatibility support and licensing restrictions, is actually a pretty compact and performant bit of JavaScript.  I rewrote it a couple of years ago when we launched our first mobile Safari website and was basically focused on limiting code size and maximizing performance.  At the time the entire mapping API was about the size of a tile to download.  It’s grown a bit since then but this is mainly through the addition of layer upon layer of legacy support and a number of bits needed to run MapQuest.com on the desktop.

With this experience in mind, I was upset to find that despite massive innovation over the past few years on the server side of open source geo, basically everyone is still focused on OpenLayers on the client side.  And OpenLayers is in desperate need of a reboot – which the dev team is doing as part of a 3.0 rebuild.  This is a great thing for anyone needing a full map-centric JavaScript map library, but it still leaves a niche for a super-lightweight, DOM-centric map library to fill in on the low end.

So you know where this is going… I started writing yet another JavaScript mapping library.  I want it to be small and fast for doing simple things (which in my experience comprises 90% of the use cases).  I’d also like it to work very closely with the DOM.  This isn’t 2005 when we were all trying to build crazy abstractions on top of the DOM to hide it.  I want to be able to have the library do enough to manage the coordinate system, tiles, etc and then just let me start attaching DOM content instead of working through layers of leaky abstractions.

It’s not all there in the head yet, but what I’ve got now will render standard web mercator tiles at arbitrary resolution, supports smoothly zooming between native resolutions of the tile server and supports attaching arbitrary DOM elements to the map by either adding a “positioning delegate” object (which is what complex elements like a Tile Layer use to draw themselves) or falling back to the default delegate which just assumes that the element has a geo property which contains a Lat/Lng and pixel offset and will take care of managing things from there.

So, very not done yet, but it weighs in at 7KB raw and 3KB gzipped.  I expect that to perhaps double by the time I get non-brain-damaged background tile invalidation and event handling in place.  I don’t really plan to add more than those basics.  The rest can be managed through normal DOM manipulations, of which there are a plethora of tools and approaches.

Here’s the GitHub repo: https://github.com/stellaeof/nanomaps

Posted in geeky, nanomaps | 1 Comment »