Random Etc. Notes to self. Work, play, and the rest.

Posts Tagged ‘javascript’

js-vector-maps on github

In Weblog on 6 June 2009 tagged canvas, Code, github, javascript, mapnik, Maps, Open-Source, OpenStreetMap with 2 comments

I've been experimenting with some javascript classes that mimic the structure of mapnik's Layer/Style/Rule classes and render OSM data (via GeoJSON) to a <canvas> element. I've also finally taken a look at how github works, so I've decided to share the initial code there in case people are interested. If you don't want to check the code out for yourself there's a demo page here (tested in Firefox and Safari only, so far).

3 For ‘09

In Weblog on 9 January 2009 tagged javascript, OpenStreetMap, stamen, Technology, Work, xmpp with 2 comments

November 2008 marked two years at Stamen for me, and I'm not done yet. Three purely technological things I'm excited about working with in 2009:

1. Realtime messaging and XMPP. After some initial experiments, I'm really excited by the possibility of visualisations driven by realtime data feeds. I like the idea of XMPP, and although scaling it out gives me the fear it's a fear I'd like to confront in 2009 on a real project.
2. Custom cartography and up-to-date maps. I'm a long-time cheerleader and supporter of the OpenStreetMap project and the project is reaching a level of completeness and complexity that competes with commercial map providers. I'm looking forward to writing tools and maps that work with OSM data in a way that just wouldn't be possible with Google-Maps-style mapping APIs or would require data well out of the budget range of most of our projects.
3. Visualisation and vector mapping in a web-browser using NotFlash technologies. The healthy competition between Gecko (used in Firefox) and WebKit (used in Safari, Android, the iPhone etc.) is improving the performance of javascript, canvas and svg (not to mention the new CSS transforms). This means that the potential for interactive vector graphics in the browser is almost on a par with Flash. I imagine the developer tools will keep me with Flash for a long time, but I'm looking for the right project to kick-start a comparable tool chain for in-browser vector graphics, and looking forward to thinking about what that might look like for myself this year.

This post could probably use some supporting links, but I thought I'd get it out there before my first week back at work ended. Happy 2009 to you all.

Processing implemented in Javascript

In Processing, Weblog on 8 May 2008 tagged javascript, Processing.org with 3 comments

John Resig, of JQuery fame, has ported the Processing language and API to javascript. Not just the API, the language too!

Mapstraction

In Weblog on 2 October 2006 tagged javascript, Maps, mapstraction, Weblog with no comments

A while ago Steve, Mikel and I released Mapstraction, a javascript library that abstracts away the differences between the leading maps APIs (namely Google Maps, Yahoo Maps and Microsoft Virtual Earth).  We wrote it so that people embedding maps in their websites needn't be dependent on one provider, especially if (when) terms and conditions are changed, or the data on offer changes (for example Yahoo's maps of London are currently very basic, but if they improve I would prefer to use their API over Google's). 

The key thing about Mapstraction is that you can switch APIs with only one line of code.  If your business depends on Google Maps then you should already be doing this, but it also seems like a natural thing to open source.  (UK property search engine Nestoria agreed, and funded the initial development).  It's already in use in GeoPress, for embedding maps in Wordpress blog posts, and Phil recently used it to add maps to Pepys' Diary.

We hope to keep Mapstraction as a lightweight layer to make porting it to any future APIs as simple as possible.  It also offers us the chance to normalise the functionality offered by different libraries, for example we offered a polyline implementation for Yahoo Maps before the functionality officially launched, and we intend to allow a choice of geo-coders for postcode and place-name lookup rather than be tied to the geocoder of your current API provider.

It's worth noting that other people are offering similar things (and more), most notably OpenLayers which offers a complete tiled "slippy" map implementation to make using with your own (or a third-party's) WMS (Web Map Server) as easy as possible.