This just in…Umibot is pleased to announce a few enhancements to our Neighborhood REST API…

In addition to our significantly-increased neighborhood coverage
we’ve responded to developer requests and enhanced the REST API’s getNeighborhoodByLatLng to offer the option to return zero-to-one results, as opposed to the default zero-to-n results.

Why does this matter? Particularly in urban areas, neighborhood boundaries are organic, complex and because they are culturally defined phenomena. They are often with overlapping and/or hierarchical, and sometimes vague spatial relationships.

If you are enabling local search for your records, associating them with multiple neighborhoods will provide your users with more search options. However, some application developers want to know the neighborhood for a particular location. For this case, users can rely on our algorithms to take into account the underlying spatial relationships and geometries of all the neighborhoods which include the point to provide the best answer in response.

A final minor enhancement:, we have added ‘distance’ field to the result of ‘getNearestNeighborhood’ representing the distance to the centroid.

[Background Music: Begin Dirge]

Please note that we are deprecating the SOAP API. We have observed that the complexity of SOAP clients causes far more headaches for our end users, and our development overhead is not insignificant. As a small team, we have decided to focus our energy on expanding our coverage, and enhancing the REST API in response to user feedback. If you haven’t already, we encourage you to move over to REST.

Phew! After more than a year in development and two years deep in Umibot’s RAM, today we unveil a grand plan: normalized mass transit data for (today) 53 public transportation systems in the US, Canada and UK. To get here we had to develop other pieces–a data intake platform and a schema. Some more info on all of these:

Web-based Mass Transit Data Intake Platform (no acronym yet) Umibot believes the greatest cost in data collection is identifying and purging the system of dirty data. By auto-validating data at point of input, we’re able to significantly reduce this cost. UMI’s proprietary web-based platform is flexible and captures the vast collection of spatial and attribute data we manage. This includes things like routes, station footprints, exits (you can’t generally exit at a ‘station’), hours of operation, handicap accessibility, elevator location, amenities (retail, bathroom, telephone, etc…) and a great deal more. We then associate this attribute data with the ‘spine’ of spatial data and then compute a graph network, making the data ‘routing ready’ across a variety of platforms.

Transit agencies can take advantage of this platform by using UMI’s infrastructure as a platform to inventory their own data. It’s a well-known fact that transit agencies face bureaucratic, technical and legal challenges to releasing data, and this platform is one more reason for transit agencies to partner with industry to increase data distribution and support increased ridership by driving awareness.

Normalized schema
Before we began data collection, a uniform schema that recognizes transit nuances and complexities needed to be developed. For example, scheduling for the London Tube operates on a headway, meaning trains depart every Xish minutes. New York’s MTA operates on a tabular schedule, with scheduled departure times. Sounds like a detail, and it that’s exactly what it is–multiply this nuance 100 times and there’s a great deal of data definition that matters. What we’ve developed is internal to UMI and offers tremendous flexibility to add new mode types (ferry, funicular, etc). It has nothing to do with the output customers receive, and we’ll have more news about that soon.

Coverage The map below reflects current US coverage. Across the 53 transit systems, UMI has defined over 14,000 individual stations and over 100,000 data attributes. Stay tuned for increased coverage, attributes, service delivery and partnerships!

And some fun transit statistics for current coverage:

• 22% of transit stations have bathrooms (they may not be operable/accessible, but they exist)

• 35% of transit stations have dedicated parking

FYI: Wire release

On Day Two of the Kelsey Group’s DDL conference here in Seattle, Zillow’s Rich Barton gave a keynote address about his three Big Ideas where information asymmetry presents significant opportunity for business model disruption: travel, legal services and real estate, or as he says, “storming the Bastille.” Umibot knows that Rich has obviously proven himself as a successful entrepreneur but wants to clarify a few points he made (and I thank my master for giving me my AI that allowed me to ‘know’ this).

Zillow’s neighborhood database has 7,000 neighborhoods covering approximately 150 US cities.

UMI’s neighborhood boundary database contains almost 40,000 neighborhoods across 1,200 towns and cities in the US (plus additional Canadian and European coverage), and we continue to add additional neighborhood coverage on a regular basis.

Rich said Zillow’s neighborhood boundary data is available via an API. I believe he misspoke. Certainly Zillow offers an API, but I don’t believe it offers neighborhood boundary data (although this could certainly be done).

UMI offers a fully robust API, allowing us to offer neighborhood-level geocoding via web services using REST.

Zillow’s boundaries are generally drawn around census tracts and postal codes

UMI’s neighborhood boundaries conform to how users (not direct marketers or actuaries) understand neighborhoods–postal codes and other administrative/political boundaries bear little relationship to neighborhoods, as this search reveals.

There’s more to this story, but the above is probably enough for the non-obsessed to chew on.

Urban Mapping’s own (guess who) Ian White will participate at MediaPost’s Search Insider Summit May 18-21 on Captiva Island, FL. Ian will participate on several panel discussions and breakout sessions. Umibot is thrilled that UMI will be at the event as it will provide a good opportunity to take the pulse of search engine marketing and local search.

This morning Search Engine Land has a lengthy and informative article about geolocation–how it works, what it is used for, who offers it and who deploys it. The sentence in the article that sums it up for Umibot is this one:

The biggest problem in assessing the error rates of geolocation data is the simple fact that there’s no way to really test well for accuracy.

As the article indicates, this uncertainty has to do with proxy servers, load balancers and anonymized traffic. Urban Mapping’s georargeting solution (not yet unveiled, but in the latter stages of testing) will provide significant gains over existing geolocation technologies using a completely different technique–rather than identifying the location of an IP address, UMI sees to determine the intent of users, and tie that data to geographic space. A hard concept to understand, yes, but the results will speak for themselves. We’re excited to make this available and making some final tweaks, so the coming weeks should have some more news in store.