So, Google failed me. The first link for Ignite Spatial NoCo was a previous event, and I didn't check the date. I ended up going to Fort Collins, and then back to Windsor. Unfortunately, I missed half the other great speakers, but the event was fun. This is my 5 minute talk from last night.
Wednesday, September 15, 2010
Friday, September 3, 2010
My Slides from TimesOpen 2.0 Event on Mobile/Geo
There were about 100 people there, and it was great fun. The developers were all really engaged. When I asked how many had used the Google Maps API, almost everyone raised their hands. I almost went home at that point. And lots of interest in Fusion Tables, which I only did a demo of, didn't put in the slides, but check it out if you haven't already.
Labels:
Fusion Tables,
Maps API,
mobile
Wednesday, August 25, 2010
Accounting for GIS
I've been thinking a lot lately about what is missing from the Geoweb. As I am 41, I naturally look back to the early days of mass computing for helpful comparisons. Thinking about the 80s and 90s, I realized just recently what I was looking for. I was looking for everyone.
Stay with me here.
Before the advent of mass computing, accountants were a specialized profession. In order to balance your books, generally you would have a bookkeeper or accountant who went through reams of paper, and did what most people thought was an arcane specialized job. Today, there are still accountants, they still do an arcane specialized job. The difference is that there is a standard type of application, the spreadsheet, that opened up a tool of their job to pretty much anyone.
So a portion of their job, playing with numbers, became open to millions of users. Spreadsheets, and the analysis of data, have become an essential tool for business. People can publish and analyze data in ways they were never able to do before, and have come up with many unique ways to use spreadsheets that accountants never would have. Arguably, Microsoft Excel is the most used database in the world, and the vast majority of users are not accountants.
That's what I want to see happen with GIS. I want to see applications where people are able to manipulate and visualize Geo data even without programming experience or GIS training. I think we've come a short ways toward that. Applications like Google Earth and Google Maps let you visualize data through a standard GUI interface. Maps APIs allow people with some programming skills to put a map on their site.
But nothing makes it easy. People come to me all the time and say "Here's a spreadsheet, how do I put all my stores on the web? Add in driving directions? OK now I want to add in other things..." Data driven apps are still harder to do. I think Fusion Tables is getting there, but needs more. It needs basic spatial queries (point in polygon for instance). And it needs the ability to upload other GIS data formats, not just KML.
But wait, I hear some GIS Pros cry, you'll take jobs from us! If people can visualize their own data, why would they need us? And besides, we do a much better job than they do.
It's true, good GIS pros will produce better analysis than the average person on their own. But I doubt that GIS Pros will lose jobs. What happened with spreadsheets was that whole new uses for data were developed. People created spreadsheets to track and chart all sorts of things. Sure, probably a few accountants lost jobs, but there are still almost 1.3 million accountants and auditors in the US, with their prospects growing. I think putting the ability to visualize geographic data into the hands of everyday users will increase the demand for specialized knowledge, increase the general awareness of geographic data opportunities, and only be good for the profession.
Stay with me here.
Before the advent of mass computing, accountants were a specialized profession. In order to balance your books, generally you would have a bookkeeper or accountant who went through reams of paper, and did what most people thought was an arcane specialized job. Today, there are still accountants, they still do an arcane specialized job. The difference is that there is a standard type of application, the spreadsheet, that opened up a tool of their job to pretty much anyone.
So a portion of their job, playing with numbers, became open to millions of users. Spreadsheets, and the analysis of data, have become an essential tool for business. People can publish and analyze data in ways they were never able to do before, and have come up with many unique ways to use spreadsheets that accountants never would have. Arguably, Microsoft Excel is the most used database in the world, and the vast majority of users are not accountants.
That's what I want to see happen with GIS. I want to see applications where people are able to manipulate and visualize Geo data even without programming experience or GIS training. I think we've come a short ways toward that. Applications like Google Earth and Google Maps let you visualize data through a standard GUI interface. Maps APIs allow people with some programming skills to put a map on their site.
But nothing makes it easy. People come to me all the time and say "Here's a spreadsheet, how do I put all my stores on the web? Add in driving directions? OK now I want to add in other things..." Data driven apps are still harder to do. I think Fusion Tables is getting there, but needs more. It needs basic spatial queries (point in polygon for instance). And it needs the ability to upload other GIS data formats, not just KML.
But wait, I hear some GIS Pros cry, you'll take jobs from us! If people can visualize their own data, why would they need us? And besides, we do a much better job than they do.
It's true, good GIS pros will produce better analysis than the average person on their own. But I doubt that GIS Pros will lose jobs. What happened with spreadsheets was that whole new uses for data were developed. People created spreadsheets to track and chart all sorts of things. Sure, probably a few accountants lost jobs, but there are still almost 1.3 million accountants and auditors in the US, with their prospects growing. I think putting the ability to visualize geographic data into the hands of everyday users will increase the demand for specialized knowledge, increase the general awareness of geographic data opportunities, and only be good for the profession.
Saturday, August 7, 2010
Thoughts on GeoWeb 2010
I went to GeoWeb in Vancouver this year, and ended up presenting two workshops.
New Features in Google Earth
https://docs.google.com/present/view?id=df795pd2_204d6g5n7d2
Going Mobile with Google Geo APIs
https://docs.google.com/present/view?id=df795pd2_207hpdznv5n
GeoWeb is an interesting conference. It has roots back to at least 2002, where it was a GML conference. It's origins as a GIS conference have colored participation for a number of years. But this year it was more than that. It's clear that most GIS professionals, vendors, etc. have gotten it, the web is important.
Though attendance was sparse, like most conferences this year, the approximately 200 people in Vancouver were enthusiastic and really engaged. I had a bunch of GIS types making their first Google Maps API app in my second session.
And there's spontaneity as well, with new sessions added during the conference.
Google's had a historic commitment to GeoWeb, and I don't expect that to change. There are some key decision makers there, and a fair number of developers as well.
One thing we have to all figure out, though, as a community is how to bridge the final gap between the web and GIS. There's a lot of efforts to do it, but nothing easy. That's the fundamental thing I think the GIS community misses out about the web, it's supposed to be easy. Any truly disruptive technology starts out simple. Maybe that's why Wave didn't work out. And anything that requires an Arc* license isn't easy either.
I'm not saying Google's figured it either, though we're moving there with Fusion Tables and the next conversion features in Google Earth Pro etc. But fundamentally, we need more features and tools that are easy to use. And cheap. Without that, we're not going to make GIS pros into mashup developers.
New Features in Google Earth
https://docs.google.com/present/view?id=df795pd2_204d6g5n7d2
Going Mobile with Google Geo APIs
https://docs.google.com/present/view?id=df795pd2_207hpdznv5n
GeoWeb is an interesting conference. It has roots back to at least 2002, where it was a GML conference. It's origins as a GIS conference have colored participation for a number of years. But this year it was more than that. It's clear that most GIS professionals, vendors, etc. have gotten it, the web is important.
Though attendance was sparse, like most conferences this year, the approximately 200 people in Vancouver were enthusiastic and really engaged. I had a bunch of GIS types making their first Google Maps API app in my second session.
And there's spontaneity as well, with new sessions added during the conference.
Google's had a historic commitment to GeoWeb, and I don't expect that to change. There are some key decision makers there, and a fair number of developers as well.
One thing we have to all figure out, though, as a community is how to bridge the final gap between the web and GIS. There's a lot of efforts to do it, but nothing easy. That's the fundamental thing I think the GIS community misses out about the web, it's supposed to be easy. Any truly disruptive technology starts out simple. Maybe that's why Wave didn't work out. And anything that requires an Arc* license isn't easy either.
I'm not saying Google's figured it either, though we're moving there with Fusion Tables and the next conversion features in Google Earth Pro etc. But fundamentally, we need more features and tools that are easy to use. And cheap. Without that, we're not going to make GIS pros into mashup developers.
Thursday, August 5, 2010
Ruminations on the 5th Birthday of the Maps API
A few weeks ago, we celebrated the 5th birthday of the Google Maps API. We celebrated again the next week. In a transpacific video conference, the Geo teams in Mountain View and Sydney ate cake and drank champagne. Speeches were made, memories recounted.
In particular, Paul Rademacher gave a brief history of Housingmaps, the first known Google Maps mashup, created initially before there was even an official API. It was thanks to the work of Paul, and several other mashup creators, that Google saw the potential to create something really special.
I often say that Google had two choices at the time. We could either sue Paul and others who reverse engineered the API and created mashups. Or, we could go with it. We went with it. I say "we" btw, as if I had anything to do with it, but it wasn't until a year later that I started at Google.
As I recounted that story at WhereCamp Socal on Sunday, I asked people what our choices were, and Tim Craig shouted out "Kill him or hire him!" Maybe that's the difference between ESRI and Google :-). (Tim is actually a great, gentle guy. As far as I know...)
It's hard to remember a time before mashups now. It's not that Google Maps was the first mashup ever, but it was the first monster mashup platform, and still the biggest. And it is having repercussions beyond people putting maps on their sites. As soon as people figured out that they could mashup maps with data, they started looking for data to do it with. And putting pressure on governments and companies to make that data available. Or simply going out and generating their own.
OK, those of you old enough to think back that far, try to remember the web before all these mashups. Still a cool thing, but not nearly as exciting. I'm old enough to remember a time before the web, of course, but that's beside the point. The fact that we can put a map with high resolution satellite imagery on our web site for free is amazing in retrospect.
The impact on the mapping community was also pretty profound. I think we're still figuring out what the implications of that are. Neogeography, the geoweb and all the other things many of us hold dear, they take off with the Google Maps API.* It is hard to imagine this, but 5 years ago who would have thought this would happen? I know it's a cliche to say that about the web in general, especially for those of us old enough to remember before the web, but 5 years. 5! Can you imagine going to a site for a retail store and not seeing a map to their location?
But there's a lot more here than putting dots on your map, showing where your store is. That's important, revolutionary indeed, but think beyond that.
Maps mashups have been used to map election violence in Kenya, report potholes in the UK, show reports of people in need after the Haiti Earthquake, convey comprehensive data about Africa, and much more. Creating advocacy maps, informative maps, or fun maps no longer requires a professional cartographer. Nothing against cartographers, but put the power in the hands of the people.
So, what happens when you start mashing up data? You start looking for more data. The confluence of the Open Source movement with the mashup community produced a call for more open data. And because of the power of these mashups to put data in front of the people's faces quickly and easily, governments had to respond. In the US, in the UK and around the world, more and more data is being opened up by governments, NGOs, and to a lesser extent corporations. Bringing data to the public is a democratization. Knowledgeable, informed citizenry can respond to their governments, and help out as we saw in the case of the CrisisCamps that sprang up after the Haiti earthquake.
We still have a long way to go. Good tools are developing, but most people aren't programmers, to take advantage of the API, or know much about geographic data. That's why I'm excited about GeoCommons and Fusion Tables, because they allow people to use tabular data (say, in a Excel), probably the most used "databases" in the world.
But all those involved in mapping on the web, pat yourselves on the back. Look where we are compared to 5 years ago. I'm guessing most of those reading this blog are involved in Geo in some way, and so I'm saying to you: Thank you, you've done a great thing for thing for the world. You're bring democracy to the world. I know that sounds hyperbolic, and I know it's not the only thing driving increased access to information. But mashups, driven by mapping mashups (Google and otherwise) are helping change the world.
In particular, Paul Rademacher gave a brief history of Housingmaps, the first known Google Maps mashup, created initially before there was even an official API. It was thanks to the work of Paul, and several other mashup creators, that Google saw the potential to create something really special.
I often say that Google had two choices at the time. We could either sue Paul and others who reverse engineered the API and created mashups. Or, we could go with it. We went with it. I say "we" btw, as if I had anything to do with it, but it wasn't until a year later that I started at Google.
As I recounted that story at WhereCamp Socal on Sunday, I asked people what our choices were, and Tim Craig shouted out "Kill him or hire him!" Maybe that's the difference between ESRI and Google :-). (Tim is actually a great, gentle guy. As far as I know...)
It's hard to remember a time before mashups now. It's not that Google Maps was the first mashup ever, but it was the first monster mashup platform, and still the biggest. And it is having repercussions beyond people putting maps on their sites. As soon as people figured out that they could mashup maps with data, they started looking for data to do it with. And putting pressure on governments and companies to make that data available. Or simply going out and generating their own.
OK, those of you old enough to think back that far, try to remember the web before all these mashups. Still a cool thing, but not nearly as exciting. I'm old enough to remember a time before the web, of course, but that's beside the point. The fact that we can put a map with high resolution satellite imagery on our web site for free is amazing in retrospect.
The impact on the mapping community was also pretty profound. I think we're still figuring out what the implications of that are. Neogeography, the geoweb and all the other things many of us hold dear, they take off with the Google Maps API.* It is hard to imagine this, but 5 years ago who would have thought this would happen? I know it's a cliche to say that about the web in general, especially for those of us old enough to remember before the web, but 5 years. 5! Can you imagine going to a site for a retail store and not seeing a map to their location?
But there's a lot more here than putting dots on your map, showing where your store is. That's important, revolutionary indeed, but think beyond that.
Maps mashups have been used to map election violence in Kenya, report potholes in the UK, show reports of people in need after the Haiti Earthquake, convey comprehensive data about Africa, and much more. Creating advocacy maps, informative maps, or fun maps no longer requires a professional cartographer. Nothing against cartographers, but put the power in the hands of the people.
So, what happens when you start mashing up data? You start looking for more data. The confluence of the Open Source movement with the mashup community produced a call for more open data. And because of the power of these mashups to put data in front of the people's faces quickly and easily, governments had to respond. In the US, in the UK and around the world, more and more data is being opened up by governments, NGOs, and to a lesser extent corporations. Bringing data to the public is a democratization. Knowledgeable, informed citizenry can respond to their governments, and help out as we saw in the case of the CrisisCamps that sprang up after the Haiti earthquake.
We still have a long way to go. Good tools are developing, but most people aren't programmers, to take advantage of the API, or know much about geographic data. That's why I'm excited about GeoCommons and Fusion Tables, because they allow people to use tabular data (say, in a Excel), probably the most used "databases" in the world.
But all those involved in mapping on the web, pat yourselves on the back. Look where we are compared to 5 years ago. I'm guessing most of those reading this blog are involved in Geo in some way, and so I'm saying to you: Thank you, you've done a great thing for thing for the world. You're bring democracy to the world. I know that sounds hyperbolic, and I know it's not the only thing driving increased access to information. But mashups, driven by mapping mashups (Google and otherwise) are helping change the world.
Labels:
Maps API
Tuesday, June 15, 2010
Map Styles and Usability: Please Help
I've been away for a couple of weeks, and I'm now catching up with what's been going in the Geo blogging community. I saw a couple of posts on the Google Maps API new styling features:
There were more of course, but Steven Romalewski and Richard Treves raise some good points about usability. We've basically provided no guidance on usability of the new styles. The examples that we provide are designed to show extremes of styling to get the point across.
The truth is, we're mostly engineers, not cartographers. I'd love to see some great guides to how to style your map. Anyone want to give it a go? Anything good out there, I will make sure we link to it and talk about it.
To be fair, Steven is also concerned that it'll actually drive more people to use Google Maps API. His concern, our hope of course :-). He is concerned that this will reduce the commitment to other mapping platforms and perpetuate a mono-culture of maps. I don't see any danger of that right now, but I do appreciate that concern. Competition is good for us, it does help drive us to better things. So Cloudmade, Bing, OSM, everyone else, please make your mapping better. It helps us too.
Labels:
Map Styles,
Maps API
Techniques for protecting your data
I was asked in the comments in this post: Maps to KML?, to talk about techniques for protecting your data in Google Maps applications. I'm finally getting around to that.
First off, let's just say that like any part of the web, it is probably impossible to totally protect your data that is published on a Google Map. People can always get access to it at very least by just viewing the data, which you want, and making notes. Screenshots, viewing source, intercepts, and other techniques can be used by the truly ambitious. True data privacy in a completely public page is an oxymoron. Note, I'm not saying privacy on the web is bad or not possible, but we're talking here about displaying data. As long as it's displayed, someone can get at it.
That being said, there are steps you can take to make it harder to get at, to make people work at it.
The most important thing you can do is avoid hard coding any information into the page. That should be fairly obvious, but many people fall into the trap. That means:
- Don't have any code in your JavaScript that uses a specific Latitude/Longitude pair, an address, or anything of that nature.
- Use calls to server resources to plot only the data necessary to display at that moment. Try to verify the origin of the requests to prevent people from scraping. Generating your data on the fly prevents someone from getting all your data at once.
- Obfuscate/compile your Javascript code to make it harder to read.
You can also rasterize your data, or turn it into image overlays. There's a lot of techniques for doing this. This talk by John Coryat is a couple of years old, and was oriented to Maps API V2. However, in it he discusses many techniques that are applicable to V3.
Rasterization makes it difficult to extract the data directly. It can also increase your performance in some cases where you have lots of data.
If you're working with KML, you can distribute the KML to only trusted people to load in their Google Earth instances, but this is subject to trusting them. Any KML used in a Maps API application will be easily findable by someone who can get passed any obfuscation you have.
That's all I've got. Feel free to post any additional techniques in the comments.
Monday, June 14, 2010
Slides from BarCamp Nairobi/ WhereCampAfrica
So, it was pretty free-form, and I didn't stick to the slides, but there's still good links and resources here.
And, I hate this, but OpenOffice on the Mac corrupts PowerPoint export somehow. This prevented me from converting to Google Presentations, so I created both a PDF version and an OpenOffice version.
The images in the Eye Candy section are clickable.
Labels:
barcampnairobi,
Earth,
Maps,
wherecampafrica
BarCamp/WhereCamp Nairobi

Over the weekend, I attended BarCamp Nairobi, which was combined with WhereCampAfrica. It was a great event, which filled both the iHub and Nailab spaces. Despite a fist fight that developed between myself, Stefan Magdalinski, and Mikel Marron, the event was otherwise very friendly and cooperative.
I went to great talks on:
- Shika (a local ICT4D organization working in the slums in Kenya. If anyone has a link, please pass it on in comments)
- AkiraChix
- OSM
- Seven Seas Technologies and entrepreneurship
- Map Kibera
And too much more to post on. But like all Barcamps, the most interesting stuff is in the halls. I learned a lot about the emerging tech community here, and the difficulties of getting work in the face of a small percentage of the population being online. Like most of the developing world, they are jumping straight to mobile, largely skipping a large scale computer market. And mobile devices are where most people get their net access.
Of course, the event had to break each day for World Cup games, which were put up on the projection screen at the iHub.
It looks like the iHub is the place to be. My only regret on this trip is that I won't be here on the 26th, when the iHub hosts a big LAN party for gamers.
For those of you in Nairobi, I'll be presenting tonight at the iHub for Mobile Monday, about 20 minutes on using Google Mapping technologies on mobile devices.
Labels:
barcampnairobi,
Maps,
wherecamp,
wherecampafrica
Subscribe to:
Posts (Atom)