DeepDarkSee

I sent this to a contact at NAVTEQ today after a conversation on mobile and maps earlier in the week at the Moto Developer Summit in San Jose.  I think this is an opportunity waiting to be leveraged, by a map vendor, or mapping web service provider (ESRI, Autodesk, you there?).  I also think that in cases where carriers mandate map providers, this kind of thinking could win contracts.

As a developer, we want to do more with maps on handsets.  We want to pan and zoom, turn layers on and off, add custom layers, and have a responsive UI experience for the user.  I looked hard for some solutions for this 2.5 years ago as we got started, and have kept poking around since.  This solution means vector maps to me, but as Google as shown, it can also be done ‘marginally well’ with tiles on handsets.  We do it like most right right now with single static images or small groups of tiles.

The key issue is that as a single developer, we don’t have the resources to build a great map display engine in our Java and BREW apps.  We also don’t want to run our own map servers (we use ESRI). 

I was (and am) really surprised that no vendor has shown up at the table offering a map display/rendering module for BREW and for JavaME that developer can adopt and use in their apps. This would be VERY leveraging for developers.I think that a company that solves these problems would be very well received.  I could even see the license for the tool require a certain map vendor. 

I could see NAVTEQ doing this, and working with companies like ESRI or AutoDesk to serve  (and enable their leased servers) vector data to the handset display components you provide.  It just seems like a win-win situation all around.  You don’t step on the toes of your content resellers or server vendors, you enable customers, and you lock in NAVTEQ as the map source.

On a related topic, I think the JSR-293 Location API 2.0, the replacement of the JSR-179 JavaME standard for GPS, provides an interesting opportunity for NAVTEQ along these same lines.  The new standard includes a map display component.  NAVTEQ could write a reference implementation of the map component, but even more interestingly, NAVTEQ could build and make available a super charged version of the implementation – not as a reference but as a value add implementation.  It could be the kind of high end vector display capability that would turn peoples heads, and could be locked to NAVTEQ content (through your existing distribution channels).  This could be part of that same “super handset map display component” work effort.

I see these as opportunities to take a leadership position, as well as advantage NAVTEQ in the mobile space.

Trackback URI | Comments RSS