Archive for the Google Category
If you’re only looking at adoption by the players like MySpace, I think you’re missing the big picture.
Sure, buy-in by these sites is going to push adoption of the APIs, but for me the real value is that this extends social capabilities beyond the sphere of these "container" sites to the entire web. If you read the Google OpenSocial FAQs, nowhere do they say that its goal is to enhance sharing between portals. In fact, they explicitly say:
This is an effort which we hope will benefit the entire web community. [...] In the future, we are planning to open-source the components that are required to run OpenSocial on your own website.
The code hasn’t been released yet, but the docs make it clear that this vision has merit. OpenSocial uses gData, AtomPub, and a whole lot of REST goodness to allow any website to implement interactive social capabilities.
I see this taking off quickly in blogging (FriendBlogRoll,etc), but I also see huge potential for things like distributed social mapping. Take a look at what Google has done with its Put Yourself on the Map capabilities. That’s pretty cool on an individual mapping level, but imagine extending that out to community maps, implemented similar to the concept of “Groups” on Facebook. Encapsulate some GeoRSS in gData (via Sean) and how hard would it be to build an OpenSocial system where "friends" can all interact with the same map through their interface of choice? OpenSocial is already geo-aware to some extent; the People data includes a GeoRSS GML Point element to locate individuals!
OpenSocial has incredible value for traditional web sites as well. I’ve been considering several different applications for my hobby website (I built this Drink Recipes website in college, and it’s stuck with me since) such as "tell a friend", "friends favourite drinks", etc, etc. All of these could be built as plug-ins for OpenSocial-enabled sites (and of course as an additional plug-in for Facebook), but they can also be exposed on the main website, turning the whole web into one big social network.
One area that I don’t really understand is how OpenSocial deals with distributed authentication. It looks like you can either authenticate locally (through user/pass) or through Google Accounts using AuthSub. I don’t know a lot about this area, but I really think that this may need to be extended to authentication methods like OpenID.
-J
Related posts
OK, so I’m breaking a promise; guess I’m a certified fanboi.
Over at Google LatLong, they just announced increased limits for KML in Google Maps. The real news, though, is that they are now following network links based on zoom extent. This means that there are more applications where you can just publish a KML service rather than messing with the Maps API.
For example (careful, it can be pretty sluggish in certain browsers) here’s my city’s main KML file displayed in Google Maps:
As cool as this is, in many cases you still have to design your KML files differently than you would for Google Earth. The browser is very limited in the amount of data that it can display–so you have to send back less data–and certain visual elements are handled differently in Maps. To deal with these limitations, there are several things that immediately come to mind as potential performance gains:
- In your network links, check the bounding box extents before returning data that is too dense for the current zoom level. Basically you just take the max (or average) of width and height, and don’t return data unless it’s lower than a predetermined value. This was the original method for controlling content in Google Earth before Regions were introduced, and is quite effective in two dimensions.
- Stay away from fancy elements like multi-geometry for mouse-overs. They don’t work in Maps. If your information can be communicated using points, then stick with points.
- If you must use lines/polygons, simplify your data so that unimportant vertices are removed
- Keep the information in your descriptions to a reasonable level.
It may also be worth experimenting with Regions to see if they are supported and make a performance difference.
Check out the original post for more examples of KML in Maps.
-J
Related posts
What do electoral boundaries and geography have in common? Lots, of course, but we rarely see this side of redistricting publicly exposed. This has changed drastically in British Columbia with the launch of the latest official Electoral Boundaries Commission website.
Despite the complexity of two distinct sets of boundaries, they have risen to the geographical challenge. On the BC-EBC website you can find the proposed boundaries and supporting information available in multiple formats, including Google Maps, Google Earth, and good old Shapefile:
Visiting the Google Maps link for my home riding takes you to a search interface showing the district outline and some basic information on population, area, and divergence from the provincial average. Be careful with this app, it’s pretty memory-intensive.
The Google Earth representation allows you to see the boundary without attributes:
And the Shapefile version has the boundaries and all of the summary attributes (shown in FME viewer, link is to a zipfile):
This is a GREAT job. Congratulations Daniel Hirner and crew, and to BC-EBC as a whole for supporting this kind of transparency!
Now, I just need to find a source of historical voting by postal code, and I’ll know the results before the voting even starts 
-J
P.S. I think I spotted some gerrymandering (just kidding):
Related posts
There’s a simple indicator I use to tell when I’m too busy at work; it’s called the FME scale. Any time it takes me over a month to play with a new feature in Safe Software’s FME, I’m swamped
In this case, it was particularly painful. I’m really interested in GeoRSS because I see the potential that it has for increasing the level of information my municipality can deliver to its residents. For instance, we could offer insight into current housing starts with a feed of new construction building permits.
For me, the beauty of GeoRSS is that it has value even without the maps. With a single format, I can publish information that our residents can view in their favourite feed reader, while allowing more sophisticated users to benefit from the spatial information.
As you can see from the following screenshots of a GeoRSS file displayed in Google Reader and Google Maps, I’ve finally found a little time to play around with the GeoRSS support in FME. You can click on the second image to see how it works. Keep in mind that the data is static, and not guaranteed to be accurate for any use:
Until now, much of the GeoRSS that I’ve had a chance to look at has been point-based, so it’s nice to have a way of generating some more complex elements in Simple and GML varieties and, now that Google Maps supports GeoRSS, an easy way to visualise it.
So anyway, how did I generate this GeoRSS file? It was pretty easy, and I’ll take you through the steps.
First, I had to set some basic parameters for the feed in FME. This image shows the basic workflow, from create a single feature with no geometry, through to writing the feature out to the “Feed” output:
Inside of the AttributeCreator, I’m setting some basic values for the feed as a whole:
Pretty simple, eh?
Next, I pull in some data from our property records database, and merge it with an Oracle Locator spatial table which holds the City’s parcel base:
And finally, I set the same the entry-specific GeoRSS parameters, this time using attributes of the building permit records instead of static text to fill in the blanks:
And that’s all she wrote. I still have to find time to fine-tune some of the attributes (such as dates and link), get some approvals, and work out the logistics of getting the data out to our external server nightly. It sure is nice that the technical part is so easy though.
If you deal with spatial data on a regular basis and haven’t evaluated FME, you’re doing yourself a disservice. Pick up the latest beta from their site (for GeoRSS support), request an evaluation license, and play around a bit. Everyone’s usage pattern is different, but I was able to justify the cost of my initial license and training with the time it saved over about six months. Safe Software deserves a lot of credit. Apart from the usefulness of FME, their support is incredible. They are the only company that I have ever dealt with where I felt I was getting real value from the software maintenance plan.
And, in case you’re wondering, they didn’t buy me a nice laptop or a 3D mouse to use while writing this. I’m just a satisfied customer
-J
Related posts
Steve Lime recently asked a question on the OSGeo discussion list about how search engines are exploiting spatial information. This is a topic that has intrigued me for a while too, and I think that the answer is that they are not leveraging this data to anywhere near the level they could be.
Google appears committed to its goal of organizing the world’s information, but they have barely scratched the surface of spatial information. Online spatial information is just as hard to find today as web sites were before Google came along.
I’m not naïve enough to think that Google would provide a spatial discovery portal without a strong incentive. Fortunately for us, that’s what separates spatial information from other domain-specific search problems: spatial context will contribute greatly to the quality of Google’s search results and provide them with better targeting for their advertising.
Google is already partway there. They have developed some strong code to parse addresses for web page geocoding, and they are already indexing spatial data and services: e00, kml, dwg, wms. Why would they not go the extra few yards (metres?) in making their index spatially-enabled? Well, possibly because it’s a bit more work than that.
On the web, you have one-dimensional documents (basically just streams of text) linked together in a massive topological construct. Indexing these documents requires you to analyze things like the structure of the document, importance of the document within its own site, and the quality of its neighbours in the web topology.
Spatial indexing is somewhat different, in at least three ways. First, within documents you are dealing with two- or three-dimensional relationships between elements. Second, spatial data is often presented in a format that looks similar to a spreadsheet with cryptic headings and numeric values; metadata is often either implied or stored in an auxiliary location. Third, there may not be an explicit definition of the projection the data are stored in, making it difficult to determine their true location in space.
The first item is important because understanding the relationships between elements in spatial documents is a large part of understanding the data. Some documents may have their elements evenly distributed throughout an entire country, while others may have data clustered in large cities. In some subject areas, documents containing a concentration of elements for a specific area might be given a higher authority rating than documents with their elements scattered over the landscape.
The second item is a difficult problem, but within Google’s ability to solve. The context of the document might be picked up from text files in the same directory, information gleaned from pages that link to the document, or the general subject of the site the data is linked from. As a user, it would be time-consuming to track down this information, but not impossible. For a computer it would be more difficult, but Google is a world leader in extracting semantic information from unstructured data. Developing algorithms to attach meaning to uncoded spatial documents is something that they are uniquely qualified to do.
The third problem is also quite difficult. Again, part of the issue is that the data may not be stored in the same file, might be stated on the page linking to the files, or may just be implied. The implied case is difficult, but not always unsolvable. For projection information, there are general standards of practice in most parts of the world. For instance, in British Columbia most local data is stored in UTM, while provincial data is generally available in one of UTM, BC Albers, or less frequently in Lat/Lon WGS84. Taking documents found on domains that have been geocoded to BC and determining the best fit with common local projections will often give good results.
I have kept my discussion mainly to file-based data sets, but I should be clear that it is just as important to do deep data mining against geospatial web services, emerging standards like GeoRSS, and the existing geourl and Dublin Core metadata tags. Fortunately, the problem domain is considerably smaller with many of the web-based formats than for file-based spatial information.
I am sure that there are other problems that will stumbled into along the way, but the benefits are well worth it: end users can have a much fuller understanding of their world, spatial professionals can easily locate the information that they need, and Google will be able to develop better profiles of their users related to their location.
So, how about it Google? Don’t you want to know that your users are coming from a location within a 25 year flood zone having average assessment values of $700000 per parcel? I’m sure that there are lots of us that would love to help you. In return all you would have to do is return spatial information in a special search or as a layer in Google Earth with a link to the source data or service
Hmm. Maybe I’m too full of myself, thinking that someone from Google might actually read this. Ah well. Might as well go for broke: I wouldn’t complain if I could store spatial information in Google Base, perform GEOS-style spatial queries on it, and return it as GML or KML… Oh, and it would be nice to be able to publish this data to Google Earth using collection pointers created with something like Google Sitemaps.
Enough whining for one day. -j
