Posts Tagged ‘melissa’

Microsoft to patent Tufte’s sparklines?! (Kottke)

Friday, November 20th, 2009

tufte_sparklines

[Editor’s note: This is total bullsh*t, the US Patent office should not be granting Microsoft patents for basic concepts that are already out in the market place as prior art and in fact invented / popularized by someone else, namely Edward Tufte. Shame on Microsoft and boo on lazy patent clerks! Thanks Melissa.]

Republished from Kottke and Tufte.

In an absurd twist, on their own Microsof blog, Tufte is credited as inventor:

For Excel 2010 we’ve implemented sparklines, “intense, simple, word-sized graphics”, as their inventor Edward Tufte describes them in his book Beautiful Evidence.

Another way to read their patent application is regarding not just placement of a sparkline in an Excel spreadsheet but any digital document. Also a bizarre claim since other tools already do that as add ins, and you can even hack this work now in Google Docs with the charting API.

Someone should start a free the sparkline petition ;)

A three-year-old’s view of the NYC subway (Kottke)

Friday, October 23rd, 2009

simple-subway

[Editor’s note: Jason Kottke’s birthday present to his nephew is a subway-style kid’s mental map of New York city. Thanks Melissa!]

Republished from Kottke.org.

This was my present to my nephew for his 3rd birthday. He loves, loves, loves the subway so my sister asked me if I could make a custom map with all the places that mean something to him on the poster.

Best viewed a bit large.

Manhattan Mapped Without a Horizon (Gizmodo)

Thursday, May 7th, 2009

uptownmap

[Editor’s note: A novel map projection based more on a fish-eye lens topology of near and far from both uptown and downtown perspectives. Thanks Melissa and Curt!]

Republished from Gizmodo.
By Mark Wilson, Tue May 5 2009.

It’s rare that we get excited over maps, but this idea by graphic designers Jack Schulze and Matt Webb would be great for GPSs, combining 3D, first person and overhead views into one übermap.

The art project, called Here & There, bends the world into horizon-less, roller coaster loop topography, which allows the viewer to see their position from the first person perspective (complete with those 3D buildings that usually just get in the way) alongside the route/terrain to come.

For now, the designers’ work is available in limited edition prints only that go for $65 (per a set of two). But we can still dream that someone like Google, Apple or Garmin might come around and drop a big pile of money on the small agency before automating this visualization for real time navigation. [Here & There and Background Info via FastCompany]

Interview with MarineMAP Mashup Developers (Kelso)

Tuesday, April 21st, 2009

marinemapsupporttool

[Editor’s note: MarineMAP is a cutting edge mashup built using PostGIS, GeoDjango, Ajax, Flash, OpenLayers, GeoServer and MapServer with Google base map tiles. It assists stakeholders in the design of MPAs (Marine Protected Areas) in mapping oceanographic, biological geological, chemical and human dimensions of the ocean and coastal areas. I talk with Will McClintock and Chad Burt of the Marine Science Institute at University of California at Santa Barbara about the technical underpinnings and development philosophy behind the project. One key to the project’s success (rolled out Dec. 2008) has been the hiring of dedicated programmers to implement design ideas and new technology to extend an earlier version’s usability and reach. Thanks Melissa and Sebastian!]

Interact with the MarineMAP at marinemap.org/marinemap.

Interactive Map Tool Objective: MarineMap is an internet-based decision support tool that provides the capacity for the SCRSG (South Coast Regional Stakeholder Group) to view data layers, create individual MPA concepts, assemble collections of individual MPA concepts into MPA arrays, receive basic feedback on how well MPA concepts and arrays meet guidelines for MPA design, and submit MPA arrays to staff as MPA proposals. This tool will be the primary way in which MLPA Initiative staff and SCRSG members capture and store information regarding MPA proposals.

marinemapsupporttool2

(Above) Screenshot above showing Marine mammal and Nearshore habitat layers on base map with area Measurement Tool enabled.

(Question) Kelso’s Corner: What technologies are leveraged in MarineMAP?

(Anwer) MarineMAP: We’re not using ArcGIS at all, save for cutting map tiles (using ArcGIS Desktop and Arc2Earth) and, as a non-critical component of the system, ArcSDE / SQL Server. We’re mainly using PostGIS, GeoDjango, Ajax, Flash, OpenLayers, GeoServer and MapServer and will soon switch to the Google Earth API.

We are using OpenLayers, rather than the Google Maps API for our “slippy map”. OpenLayers is pure javascript, as is most of the client application. We are using Flex, but only for the charting component. [Editor's note: OpenLayers is using the Google Maps tiles.]

(Q) Kelso’s Corner: How many programmers do you have on staff to deal with all the software components?

(A) MarineMAP: Currently, two of our developers work full-time on MarineMap, while our other two developers work half time. We also have several GIS analysts and a cartographer to deal with the data end of things. We are now looking for a full-time, in-house Assistant Web Developer to continue working on MarineMap. As we extend MarineMap to different geographies and planning processes, we anticipate that we’ll be looking for one or two more programmers as well.

(Q) Kelso’s Corner: What was the rational for doing this substantial map development in house? Did you evalutate other routes, consultants, off the shelf software before going this route, why was this option preferable? Did you have a good cheat sheet for how to develop / implement this technology? Did you have to hire new staff to do the programming or did you have existing expertise to draw on?

(Anwer) MarineMAP: We did not have a cheat sheet for how to develop / implement this technology. This was a brand new application using some new technologies, and some that we were familiar with. Of course, we had experience developing other applications and some of these technologies overlapped. But, there was a significant amount of learning happening for all of our developers.

The MLPAI is an on-going process that will terminate sometime around 2011. Until then, we need to have a highly functional and stable application that can be adapted to the changing needs of the process. It turned out to be much more cost-effective and time efficient to hire in-house developers to work on the application year-round. Before we built our team, we spent a significant amount of time considering a host of alternatives, including trying to maintain and tweak Doris, contracting out all of the work, etc.  Initially, we felt we did not have enough in-house expertise. Although we already had Chad Burt (UCSB), Jared Kibele (UCSB), Tim Welch (Ecotrust) and, now, Ken Vollmer (Ecotrust) as our in-house crew, we eventually contracted two developers from Farallon Geographics (Dennis Wuthrich and Alexei Peters) for a limited period to  help with developing the database schema. This was particularly nice given that we had only 6 months to get the first version of MarineMap out the door. Dennis and Alexei are no longer working on the project but I am very grateful that we had access to their time and expertise during the initial phases.

(Q) Kelso’s Corner: What was Doris?

(Anwer) MarineMAP: At the beginning of the Marine Life Protection Act Initiative (MLPAI), staff chose to hire consultants to build an application (eventually called “Doris”) that was built on ArcGIS Server 9.1 technologies. It shared some of the features of MarineMap, including drawing MPAs and arrays, and generating reports on what was being captured inside those MPAs. Doris had a poorly designed interface and, perhaps more significantly, it was dreadfully slow. Consequently, few stakeholders used it. Furthermore, because the application was built using technologies with which we had no particular in-house expertise, and because these technologies were proprietary, we had a difficulty updating the application or tweaking it on the fly. (I had been running ArcSDE / ArcIMS and ArcGIS Server applications for a couple years but had no real development expertise in, say, ArcObjects, or VB .Net.)

(Q) Kelso’s Corner: It seems there are many more RubyOnRails developers than Django. Have you found this a hindrance for hiring staff or when looking for trouble shooting advice?

(Anwer) MarineMAP: It does seem to be a bit of a challenge finding Django developers, particularly those that can / will work locally. I have not tried to hire a RubyOnRails expert so I have no direct means comparison.

(Q) Kelso’s Corner: Why will you be switching to the Google Earth API? Is this only for the front end? Have you been happy with GeoDjango?

(Anwer) MarineMAP: GeoDjango has been fantastic. Using the Google Earth API does not mean ditching GeoDjango. Rather, using the Google Earth API represents a shift away from the OpenLayers API. We’ll still be using GeoDjango extensively.

[Our lead developer] was a big proponent of RubyOnRails for quite some time, but Django has taken many of its best ideas to Python. While Ruby is aesthetically a beautiful language, Python is usually much faster and has a more mature set of modules to build on. The only thing I miss after switching over to Django is the database migrations Rails offers. Most open source GIS packages also have bindings for Python, where as there a few similar tools for Ruby.

Switching to the Google Earth API will just mean replacing OpenLayers. OpenLayers is a very good library, but the Earth API is much faster due to the fact that it is a compiled plugin rather than being written in javascript. This allows it to display thousands of placemarks on screen at once, which is one of the primary reasons for switching. Google Earth can also display temporal and 3d data.

(Q) Kelso’s Corner: Besides the change to Google Earth API, what other changes, updates do you plan for this online map?

(Anwer) MarineMAP: Besides switching to the Google Earth API, there is one major upcoming update to MarineMap. Specifically, we will be implementing a map-based (i.e., location based) discussion forum. Users will be able to zoom into a location on a map and tag objects (MPAs, data, places) with a comment. Other users will see these comments (if they have comments “turned on”) as they zoom in to a location or if they load an MPA. Users can then participate in a dialog via a traditional discussion forum that is linked to the map. Furthermore, users will be able to define a geographic region and subscribe to RSS feeds (using GeoRSS) for any activity within that region. One might choose to do this, for example, if they want to be notified by email any time somebody draws a new MPA in, or makes a comment about a data layer in a specific region that he / she cares most about. I believe the map-based discussion forum will go a long way in facilitating discussion about MPAs, particularly outside the in-person monthly stakeholder meetings.

Conclusion: Thanks so much for the informative Q&A session. Please check out the MarineMap project at MarineMap.org/marinemap.

Watch the Road: World’s Earliest SatNav (Strange Maps)

Wednesday, October 1st, 2008

[Editor’s note: Republished from the Strange Maps blog. Thanks Melissa!]

Satellite navigation (SatNav) is a lot older than previously thought. In fact, it’s even decades older than man-made satellites themselves. This fantastic contraption, called the ‘Routefinder’, showed 1920s drivers in the UK the roads they were travelling down, gave them the mileage covered and told them to stop when they came at journey’s end.

The technology – a curious cross between the space age and the stone age – consisted of a little map scroll inside a watch, to be ’scrolled’ (hence the word) as the driver moved along on the map. A multitude of scrolls could be fitted in the watch to suit the particular trip the driver fancied taking.

The system has several obvious drawbacks – a limited number of available journeys, and the inability of the system to respond to sudden changes of direction. Also: no warning of road works or traffic jams ahead.

Not that there were that many traffic jams in 1920s Britain. The Routefinder, one of many bizarre patented gadgets now on display at the British Library, didn’t take off because there were too few drivers, i.e. potential customers, at that time in Britain. Or maybe also because it was a bit impractical, distracting drivers from what they were supposed to watch – the road.

Many thanks to Toni Hudzina for sending in a link to this story (here on ananova).

Close to Home (Comic)

Wednesday, June 18th, 2008

map quest close to home comic

Caption: MapQuest Inc. :: Phil blows his interview before even sitting down.

Thanks Melissa! Original on the Close to Home site here.