There is a lot of discussion, and projects, about developing solutions that address people being able to engage with HyperLocal information. In fact, the project names speak for themselves: UpYourStreet, EveryBlock, etc.

Having lived primarily in the suburbs or small towns that have a less diverse, or at least small scale distinctly diverse, culture to them, I could understand, but not relate, to this concept. From my background, one block was nominally the same as the next, there was little direct difference between them and granularity was limited to the “area of the city”.

But having lived the last month in San Francisco, and more directly, in the Tenderloin, I learned very intimately about this concept - but also think it falls short and is potentially too expansive in it’s area.

The Tenderloin has a reputation for being rough and tumble, or edgy. What this translates to is that the various streets and alleys are filled with vagrants and drug abusers. The Tenderloin purportedly gets it’s name from cops that worked the area and would take bribes for shady deals - and as a result they could afford better cuts of meat from the butcher.

The on the ground reality is that the Tenderloin looked at as a single entity has shady aspects. However, it very much depends on which street - and even which part of the street, side, and facing direction. From the apartment I lived in, one chose their routes based on time of day. Heading east and north were through safe streets, past hotels and restaurants - but south and west were past shady dealers, well frequented liquor stores, and generally unsafe situations.

Looking out from from my apartment I could see 270 degrees - to the north was a Hilton, the west was a church, and south were liquor stores and constant groups of impoverished and drug abusers. Across the street from the Hilton on the south side is a Cuban Restaurant and a shop selling X-rated videos, and to the west is a upper-end wine store and chic Vietnamese-Fusion restaurant.

This is just a single viewpoint in one area of the neighborhood, but summarizes the general topology of the Tenderloin.

View the entire Mapufacture Feed

A View of Two Services

This was most succinctly demonstrated right outside my window. I overlooked the Glide Memorial Church, on the corner of Taylor and Ellis - a gorgeous building that made my view one of the best in the area. Glide is renowned for it’s Sunday ‘Celebrations’ that are more like group concerts than church services.

The services are so well attended, a line starts 30 minutes before the doors open, lining up along Taylor heading north.

Glide also serves a vital service to the community in providing meals and shelter for vagrants. The line for people to line up to receive meal tickets, or to head in for the night, lines up along Ellis heading west.

So at 11AM on a Sunday morning I would look out my window and see from a single perspective two very different worlds, on one corner you had low, middle, and upper class families from the city, as well as tourists and visitors waiting to attend services - and on the other corner was a mirror reflection of low and impoverished people lining up for food.

Tenderloin National Forest

The Tenderloin was always full of surprises. One morning on an expedition from the east corner of the Tenderloin, to the far west end heading to the Scone Factory, Corrie and I were astonished to stumble across a true hidden gem: The Tenderloin National Forest, tucked into Copland alley.

While the various neighborhood projects are doing great work, as Steven Johnson points out it’s also difficult to provide a nationwide interface to what are very local issues and perspective. So local that if you geocode to the wrong side of the street or around a corner, you have completely changed the context of that information.

Fortunately, there is a project underway to enable the community map the neighborhood. In a small area that has such variety and required local knowledge, it is vital for them to mark viable business and residential areas in order to encourage development. I think projects like this are vital to fill-out the localized aggregation services and provide a truly super-hyper-local perspective.

SuperHyperLocal Tenderloin - a photoset on Flickr

A commonly requested feature addition to GeoRSS has been multiple locations per entry. Currently, GeoRSS only adds a single geometry per RSS or Atom entry. This was pragmatic and served the general goals of GeoRSS.

There are several commonly encountered use cases. News reports typically mention several locations. Bloggers using GeoPress may tell a story about a trip and want to reference several spots along their trip - especially if they are documenting a tour that includes a path and sites along that path such as in EveryTrail. Dan Schultz talks about why “One Location Doesn’t Cut It”, citing other examples from news journalism.

Adrian and I recently sat down together to quickly brainstorm on what this may look like. The features we were looking to add were: multiple geometries, excerpt for that geometry, and toponym for that location (venue, city, etc.) Additionally, we didn’t want to break current compatibility.

Other services are already including multiple locations in different ways. Flickr outputs a single location in two different formats of GeoRSS: Simple, and some odd form of deprecated W3C. MetaCarta’s RSS-to-GeoRSS converted currently just dumps multiple locations into the entry, but without identifying if these are unique locations, or just variations in format type or hierarchy.

We wanted to call out that this is in fact a different type of geometry - a multi-geometry. Both KML and WKT support multi-geometry, but without being able to reference what the points are individually about. That’s useful if you are, say, marking all the holes in a field, but not for narratives.

Another feature we wanted to try and support was to be able to reference geometries stored elsewhere. Currently in GeoRSS feeds you’ll typically see references to a City or Country just include a point to the center of that geography. Not really indicative of what the article was about, or useful when trying to find all the geographic data about an area. So it’s important to include lines and areas as appropriate. However, including huge outlines of states or nations, potentially multiple times within a single feed, can have drastically bad consequences of increasing feed file size and complexity.

Here is a snippet of what we are proposing:

The first part to notice is that we wrapped the multiple geometries in a georss:collection. This allows current parsers to not be confused by encountering multiple georss elements unwrapped and being unclear if they are multiple representations of the same geometry, or different geometries.

We also included a excerpt attribute that allows you to include some text referencing what this location is specifically about. This can be text from the article itself, or some other useful information. One concept we had considered was using some reference to the text wrapped in the article itself, but this seemed burdensome and prone to problems using an attribute of one element to embedded text in another element.

The second element is a georss:polygon that includes a src reference to the geometry stored elsewhere. The rel tag specifies that it is the geometry of this element, and the type helps the tool know what the representation is of the stored geometry. This way a tool that is consuming the GeoRSS can go and fetch the geometry if it wants, or if it already has a cached version, say referenced elsewhere in this same feed, then it doesn’t have to request it again.

Of course, with a standards development, it is useful to consider how a user interface might provide for including multiple locations in an entry. Here is a mockup of how I imagine a simple interface would appear, and probably how we’d implement it in something like GeoPress:

Article: We went to visit downtown Cedarburg before the conference. Had some great sandwiches at Joe’s. If you haven’t been to Cedarburg, Wisconsin, then you haven’t really experienced the MidWest…

Locations:
- Excerpt: Went to visit downtown Cedarburg…
- Type: Point
- Geometry: 43.296700 -87.987500
- Name: Cedarburg, Wis.

To promote ideas and discussion around these and other proposals, I’ve created proposals at GeoRSS.org on multiple location and referencing external geometry. Please let us know what you think about the idea and format. We know that we can’t please everyone, but like the origins of GeoRSS, we’re just trying to address a real need with a simple format.

Yahoo Brickhouse finally released their new shiny FireEagle service. If you haven’t heard of it before, FireEagle is a user location brokering system. No more, no less. It provides a secure authorization system and interface to allow third-party applications to update a user’s location, or query a user’s location.

There have been, and are, other location sharing systems. Most recently, Plazes, TwitterVision, my.loki, Loopt, Dodgeball, and more coming online soon. However these systems were either hampered by being too much, not providing good interfaces, unclear security and authorization, and worst of all, user lock-in or siloing. Those services have great purpose and use and communities, but they aren’t the cross-application interfaces they could be.

What’s incredibly exciting about FireEagle is that it does one thing really well - and provides excellent hooks for using this information. It’s a service about user-geolocation enabling other applications. Its one of those services that a user comes to for signing up, but after that never needs to come back to FireEagle at all. Applications build in authorization, publishing, and accessing their location into their own interfaces.

And even better, you can publish your location from one system, say a mobile device, and have other applications access this, say from a social network site.

This concept follows the concept of loosely coupled systems. Other location sharing systems typically required all potential users to be members of that particular service, using that interface. For example, I can’t view locations of my twitter contacts in Plazes, or from a single mobile app - where a combined interface has utmost importance.

I’ve recently updated my blog, and included in the header my current location from FireEagle. I can now set my location via Dopplr, mobile phone, dashboard widget, or whatever cool next generation shoe tracking service, and have my site automatically get this - or view in FaceBook.

FireEagle will do for geolocation what GoogleMaps did for online maps, or Twitter did for small messaging exchange: Provide an underlying framework that developers can innovate on top of.

I explained before why the iPhone doesn’t need a GPS, and FireEagle makes this especially true. In the end, I just want it to be easy for me to share locations with people and use this for finding things around me. I don’t really care how that happens, I just want it to happen. And loosely coupled systems like FireEagle abstract away the geolocation method from the geolocation-sharing.

Unfortunately the blog is agog so far today with numerous posts by misunderstanding newszines that see it useful to bash FireEagle and comment on “lack of apps”, or “user base”. They’re not understanding the concept that FireEagle is a tool, not an endpoint.

I hope FireEagle doesn’t get feature-itis. Users and devs are asking for social networks, stored location names, and other features that each have their uses, in specific application spaces. But FireEagle is powerful for just the reason that it doesn’t do all these things. It’s like saying Amazon’s S3 needs to have “Friending”. External applications should be innovative with how they use and extend FireEagle.

You’re already seeing applications add integration. Dopplr will set your location once per day based on your trips, PresenceRouter helps join FireEagle into the other geolocation services. Dangerday is a Twitter bot that will allow you to publish to FireEagle from the plethora of Twitter applications and sites out there. FireWidget is a Mac OS X dashboard widget, and FireWrench is a GreaseMonkey script for polling your location in Firefox. There are a couple of other really exciting applications and interfaces to FireEagle that can be found with some lurking around (I leave this as an exercise to you the reader until the apps officially announce themself).

We’ve also built in FireEagle support into Mapufacture and will soon be showing off some of the really interesting things FireEagle lets us do for our users.

Jesse Newland has a very good ruby library, and I believe the Yahoo Developer Network will be putting up libraries for PHP, Python, Javascript, Java, Objective-C, and C#.

FireEagle is also using the new OAuth specification - one of the first large scale service to do so. Along the way they’ll have to do a lot of developer education on how to use OAuth, but it’s a leap in the right direction. Using OAuth it makes it simple to connect to multiple services without having to cater to as many unique authentication mechanisms. The pain is early in development but pays off in the end.

So developers - this is a call to you, go out and build cool stuff with FireEagle!

Last Semester I sat in on a course at the University of Michigan taught by Sandra Arlinghaus and Ann Evans titled: Maps and Timelines: The Quest for Peace in the Middle East.

I approached the course as a technologist looking to expand my knowledge of application and techniques of GIS and web mapping for addressing social and environmental issues. It was an interesting experience due to the fact that the rest of the class was primarily education and middle-east studies students, with very little technical capability.

Throughout the course we discussed what Arlinghaus and Evans are calling a “Geomat”, a geographic matrix that formulates a standard ‘recipe’ for building a hypermedia visualization of anthropological issues. This includes both pertinent data: climate, demographics, terrain, resources, economic and social institutions, individual actors, and policy; as well as multiple interface elements: maps, calendrical timelines, individual events of interest, biographies, source documents, and organizational reports.

Overall, this is an excellent concept for how to design an informational and exploration site to document and educate on an issue. Too often a site is full of text that is typically opaque to understanding by the average reader, or simple pretty graphics that are too easy to tell the single-side of a story or mislead and under-represent. Together all of these elements can serve to provide the user with a multifaceted understanding of an issue - from technical to anthropological perspectives, and provide a better analysis capability in which to frame future discussion.

The culmination of the course as building a project around a specific event or issue in the middle east. Inspired by Corrie’s work, I chose to investigate and map the consumer water issues and in general hydrological capabilities and rights that has underpinned most conflicts and discussions between Israel, Palestine, and other countries in the region like Jordan and Egypt.

http://mapsomething.com/demo/waterusage/

The Data

Gathering the data for this project proved to be particularly difficult. After a lot of searching I did start to find some very good static maps generated by the UN and some of the Israeli Agencies. None of these provided the underlying data and as such did not provide a mechanism for investigation or combining with other data.

This actually illustrates part of the problem why there is such conflict over water in the region. Maps tend to be limited in the data they show - either being hydrological maps, or infrastructure maps, or political boundary maps. However, the situation is more complicated and inter-dependent. Issues over security fences and borders typically move boundaries several miles for no apparent reason. When you bring in well locations and other infrastructure, the reasons become very apparent as the fence may be moved to provide access to a small number of wells to one side or the other.

A larger, more prevalent issue is the actual location of the aquifers and the effect that inhabitation and construction has on affecting the quantity and quality of water of residents much further away. All the water from the West Bank (Eastern side of Israel) flows towards the Mediterranean and affects the coastal aquifer. Therefore Palestinian usage and maintenance of this water source affects Israelis, a situation that has obvious unsettled many in Israel and underpins negotations.

Finally I was able to get some very useful data from the Executive Action Team (EXACT) Multilateral Working Group on Water Resources, which is tasked with gathering data and providing analysis and sources for this very issue. In addition, networking with David Katz of the University of Michigan and Michael Eyal of the Hydrological Service of Israel got me better aquifer and stream data. These and more resources are listed on the site here and I’ve also included the converted data formats and uploaded them to Mapufacture.

The Technical

Being a technologist, I wanted to build a ’slick’ way to generate my Geomat with dynamic content from a common data store. It’s been a very long time since I created a “static” site that wasn’t generated from some form of a database.

For the Israel & Palestine Water site I chose to store all the information in KML. The richness of KML allowed me to specify styling, temporal, and other attributes such as actor (country) and category (water, conflict, meeting, individual).

I then built a simple PHP page that parses the KML and populates the map and two timelines. The two timelines has drawn some criticism, but I wanted a way to show both major events for quick navigation - kind of like a shortcut menu, and then a more complete timeline that showed all events on a very fine timescale.

The underlying tools used also included Mapstraction, which made the overlay of markers and polygons for watersheds very easy, and Simile Timeline, which has excellent support for time visualization. Tying the two together was straight-forward and my Javascript was inspired by this Earthquake Map/TImeline demo.

At the end of the project I added a Mapufacture map at the bottom of the page that brings in dynamic and up-to-date news of the region pulled from a variety of sources including news agencies, blogs, and media sharing sites. Ultimately, I would like to overlay this dynamic information onto the primary map, but there are definite issues to be addressed with usability with so much data and making it usable and understandable.

That last part really summarizes the entire issue that Geomats and other design patterns are attempting to resolve. How do you provide for a very rich, and deep, map interface without overwhelming the user and providing mechanisms for exploration and investigation. There is some utilization of the timeline to filter the viewed events, and being able to select markers either geographically or temporally, and have the alternate display centered also aids in guiding the user in connecting the entire set of complex issues.

Also check out the other Maps & Timelines projects, especially Esmaeel Dadashzadeh’s analysis of the efforts to data and investigation of the currently proposed solutions when analyzed using this Geomat multifaceted approach.

Erik Wilde was pointing out the disparities between Google Maps and Google Ditu, or their Chinese version of maps. However, Google Ditu doesn’t have satellite imagery.

There are several easy ways to fix this. The first was to look at the Ditu tiles, and confirm they are the same as Google’s nominal tiling scheme. Which means you can add the China Street tiles as a simple GTileLayerOverlay with Google Maps standard satellite view underneath. This was incredibly easy with Mapstraction and I put up a demo here.

For bonus points I even added a Mapufacture syndicated feed of Erik’s venues for LocWeb2008 and nearby Wikipedia articles from Geonames.

The other way

The terms of how mixing Google’s various tiles together isn’t clear. So the other way to address his issue is to use the freely available data.

Namely, OpenStreetMap for roads, OpenAerialMap or other remote imagery, and run in OpenLayers. Here is the same map done with open data and open source. The resolution or completeness isn’t there yet, but you can see where it’s going and the ability to be use the information as you want is very appealing.