As in, literally…

Today we’re excited to announce a partnership with Intelligent Direct, the market leader of custom print and data solutions for business. Through publication of custom electronic and printed maps of all sizes, companies can better manage the impact of location, geography and demographics.

Urban Mapping’s neighborhood boundary database will be incorporated into custom solutions. IDI’s MarketMAPS division has served thousands of clients in its 25+ year history.

Umibot is most excited about the offline possibilities. Even though it’s not clear if a bot can exist in the real world, there’s no question direct marketing does. And it’s huge. And small/medium-sized businesses think about overall marketing impacts and budgets, not segmenting by channel. This announcement is the first of several to link interactive and direct marketing efforts.

-The official news

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 at the TechCrunch40 Conference Urban Mapping announced its latest customer–we’re thrilled to count Microsoft among the portals that utilize UMI’s products. Now may every man, woman and child find their way through congested and urban areas!

A several weeks ago we posted a few thoughts about the death of the ZIP code. There’s a lot more to say from the geo-perspective on local search, and here’s some more fodder…

To give any data a geographic context, it must be spatially-referenced to the Earth. Geographic information systems (GIS) serve as a means of referencing this information. Within the context of local search, addresses, city boundaries, postal codes or other geographic data must be ‘translated’ from human terms (690 Fifth Street, San Francisco) to latitude and longitude, ie, machine terms (37.775429, -122.397314). This geocoding process allows databases to recognize human-language requests. To geospatially reference (say) a postal code, one would expect that area to be spatially-defined. When a user searches for (say) “coffee in 94107,” the ZIP code should serve as the geographic constraint, searching within this polygon. Correct?

Wrong! A variety of reasons are to blame for why the logical doesn’t happen: most obviously, ZIP codes were defined as letter carrier routes. They were not meant to serve any other purpose. As such, the ZIP may not even conform to what you expect–one side of a street, one floor of a multi-story building or one-half of a block may not be fall within what postal code you expect. In fact, many parties claim to use a ZIP code database in fact obtain this info from a sister governmental agency, and these boundaries are stylized representations of the USPS data.

More to the point, these stylized boundaries are likely not used. Instead of associating (say) 50 latitude/longitude points to define a the postal code boundary, technical optimization says one point is sufficient. The analogy here is reducing a novel to a word–in the context of local search, granularity matters, and using the mathematical center of a polygon serves to distort and misinform a user’s search. In practice, the centroid is used because it is more efficient to calculate than the actual shape. Reducing the contours and nuances of a small area to a point, often with a radius drawn around it, effectively makes all postal codes look like circles. Gaps and overlaps are formed, further distorting the expected reality for a user.

Graphically this can be represented with the ZIP code boundary and circle (with the center serving as the centroid). The circle includes area that is not shared with the postal code area and vice versa. A user searching in this ZIP will therefore not be returned all the relevant listings. Some will argue this is a technology issue, but from the above example, it clearly more of a mindset–getting product managers to think about the how and why of data will go a long way.

This morning at the O’Reilly Where 2.0 conference we announced our latest customer. UMI is thrilled to be the latest MapQuest partner. We look forward to millions of users being able to search in an intuitive manner!

UMI’s Ian White will be participate in a local search panel at Search Engine Strategies Toronto, June 12-13 2007.

SuperPages.com, the Internet Yellow Page (IYP) product from Idearc (formally Verizon Information Services, has licensed Urban Mapping’s neighborhood database for its local search platform.