So Google recently launched Street View. Quite cool.

But the question begs itself - how will this be kept upto date? The greater the reach (ie more cities), the harder for Google to keep upto date. Are they only going to cover a dozen major cities in the US? How often will the data be updated?

Curious how it plays out.

Information is coming with such rapid pace that it can be overwhelming. To keep ourselves organized, we keep topical references on what where and how.

So - launching next week (or the week after) will be WeeklyLocal.com (no site up yet). It will be a digest of what is going on in the local space, released every monday morning at 5 am EST. A way of keeping abreast with local without information overload.

At the same time - I still highly recommend you keep up with local blogs like Greg Sterling and Peter Krasilovsky - not only do they have fast-paced news, but their insight is fantastic (and they are friendly people to boot).

So I came across a post on Loki over at Screenwerk, and decided to take a closer look.

The premise is interesting - using wifi triangulation it is able to discern where a user is located. This is great for anything localized - eg local search. From our own experience a lot of users don’t even bother with entering in the ‘where’ field - what they expect to get, I still haven’t figured out.

So - you have to download the toolbar for it to work (thankfully with both Internet Explorer and FF versions). The toolbar takes a while to install, and for a desktop computer, it falls back to figuring out where you are based on IP. It would have made sense that, once realizing this was not a wireless computer, it would have prompted me for my address. Instead I had to initiate this process. Even more - I am very concerned about my privacy. I would have appreciated it if I could have just entered my ZIP code - instead it demends a street address.

The system is a bit sluggish - adding channel seemed to freeze up my computer, as did searching anything through the toolbar.

It works well. I went ahead and submitted iBegin Source to be included in their list of search engines.

But the real issue here is their new ‘Javascript API’. Using this API you can do ping the loki servers to figure out where a user is (provided he/she is using Loki). With the latitude/longitude of the visitor, you can easily serve up localized content.

But - it seems very muddled. The code itself is really simple - a few lines where you connect with the Loki server and extract this information.

But there are too many negatives. First of all - if Loki.com goes down, your site performance will degrade (due to the JavaScript call). I can trust Google will be up (for Google Maps) - but Loki?

Second of all - the restrictions seem rather arbitrary. We are given 10,000 location transactions per day - what is a transaction? Is one transaction one lookup (even if the user isn’t using Loki). Or is it only a transaction when the user is using Loki?

Lastly - the badges page. Provided we can get over the previous two issues, if I want a user to utilize Loki, I don’t want to send them to a common page. They are my visitor - I don’t want to be sending them to a competitor’s site. For the badges to work, they must provide a ‘clean’ landing page with minimal distractions. A link at the end saying ‘Visit Loki.com for more location-enabled sites’? Fine. More than that is too much.

At the end of the day, what I am curious about is - how many people are actually using Loki? Getting iBegin Source to work with the toolbar took all of 2 minutes - just do a check if latitude/longitude are set. But utilizing the JavaScript API requires a lot more work - are there enough Loki users to make it even worthwhile? While I hate to use those online ranking sites, the early indications are not so good.

An extension of my previous post on data processing, thought I would share this interesting tidbit:

iBegin Source is so large that its sitemap is split into 1115 files. The total amount of disk space (we generate them once a day for performance reasons) used up just by the sitemaps is 3.2 gigs.

Just uploaded another 4.6 gigs of data today - fun job processing it

Pretty soon the mailman is going to be a pretty good friend of mine - every other day he seems to be bringing me something that needs my signature (usually a DVD/CD with more and more data).

What people often miss is that for maybe every record you see, there are 3-5 behind keeping everything aligned up. From timestamps on everything, to IPs on everything, to user IDs, reasons, sources, referrers, logs (a biggie) etc etc - it is of critical importance that everything be tracked.

A multitude of reasons too - from hack attempts, to backups, to bugs in the system - it is extremely important that we know (if we need to) what is going on at the microlevel. Just as important are macrolevel trends - important when keeping an eye out to make sure things are working fine.

In the case of iBegin Source, each state has six tables (the data dump portion is half of one table). These tables are all important to make sure everything is lined up and synchronized. This does not include any of the raw data (which spans untold amounts of gigs and tables) or even the dev area. Heck the search database has ~40k tables and 150 million entries - not the most effective, but it has reasons inherent in scaling purposes.

And to be sure - there is a ton of manual verification going on. From entries mis-spelt (cheap data-entry?) to condensing multiple entries to one - the business of data is not a fun one.

BUT - it is a double edged sword (in a good way). We sell the data. And we utilize the data. I was on the phone today with someone who was very interested in our approach - I keep telling everyone that we do local (and thus - all of our ‘products’ are us doing local). I think other data providers (in fields not even related to local) are going to start following this lead - instead of just being a enterprise provider, why not also click with the consumer directly? The recent move by Yahoo to take its mapping in-house is a perfect example - it is exactly what we did. Instead of relying on a provider, we are going to the raw sources and amalgamating on the data ourselves. This of course leaves the enterprise provider in a sickly situation - enter the consumer market, and piss off the enterprise customer. Don’t enter the consumer market, and hope the enterprise customers don’t leave you.

I’ll touch on this more in-depth later.

We’ve been gearing up to launch our own wiki-system for places soon, but have run into a few issues.

So I wanted the time to showcase two places:

Wikimapia - the grand-daddy of map/wiki sites. A ton of rich content. But unlike more traditional ‘wiki’ sites, everything is locked in. As of right now, the site claims 3,703,330 places.

ShapeWiki - A lot cleaner in approach, I really like this website. Has some fantastic export options. Especially intelligent is how they do their mapping - adding a point between two points allows for a lot more flexibility, and was a very intelligent design choice.

I came across Mini Cities late yesterday, and it is an interesting model.

The basic gist is simple. Properly covering a large area of local is difficult - the manpower required is quite intensive. So - why not build a stable platform/system that allows a person to quickly setup a website for his/her local area?

The definition of local seems to be amorphous here, as ‘New Tampa’ is not really a city per se, more of an area/locale (if you live there, you know what it is). As such, this means it is exclusively geared for local residents (about 25% of our traffic on iBegin Toronto are tourists).

The sites themselves are not bad. They have made the urls fully search engine readable (though the actual url structure is odd - eg seems to include ‘restaurants’ and ‘coupons’ in all of them). The standard items of local interest are here - events, business listings, coupons.

The ads (where I expect most of the revenue will come from) are all on-site links to locations with coupons. I think of this as a shrewd move - having people using these coupons with local businesses proves to the business that there is viable traffic and leads - much easier to sell ads later.

I do wish the sites were more customized design-wise. I did notice that the logos are unique, but otherwise the designs are identical. I think it would be a great idea if they had a dozen or so templates - franchises will want a bit more control over the design, and being locked into one standardized one isn’t that. The events also need a calendar - a listing is nice, but I (along with many others I am sure) prefer a calendar-view.

Regardless - the question at the end is how well the company will be able to sell franchises (and for how much). I am sure people are itching to try their hand at making money from a website, and the ability to do it locally seems very appealing to me. Time will tell if they have the right ingredients.

Thought some of my readers would be interested in the upcoming iBegin v3.

So we launched iBegin Weather today. Focus is on clean and easy.

We also have a weather widget. Again - focusing on clean, you don’t even need a visible link to iBegin (or any branding). The hard part of course is promoting it - maybe I can put my earlier look Coupon Looker’s widget to good use.

This is half feature/half site - I don’t think we could run with it on its own, but as an extra feature of iBegin I think it becomes more powerful.

And you could always digg this.

iBegin Source has been around for over a month now, and we’ve had over 2500 non-commercial downloads (more on that later).

I thought I would take the time every few months to showcase a few sites using our data.

First up is Restaurant Reviews. We had a bit of hand in this product - the design was done by our design firm, Design Disease.

I absolutely love the design. I am definitely biased here, but I really think it has one of the nicest/cleanest UIs a local site has (I will admit - even nicer than iBegin’s).

The site is very fast to use, but I do wonder how they will get users involved. I talked to the two operators, Anita & Todd Cowan, and they promised me they have some interesting ideas. They did underscore that they want to remove anonymity and focus on the ‘meat’ - actual reviews, not stories and tales. Time will tell how it goes, but it does look good, and it does respond fast. I’ll do a follow up in a couple of months.

The other site is OddPath.

OddPath is an interesting one, a lot due to what happened in the background.

The site was developed by Kailash. Very smart and very talented (we acquired Commentful from him). When we had launched iBegin Source, I had showed him the site.

A few weeks later, we were chatting about performance optimization for searching through 10+ million records. After some discussion, he mentioned how he was working on a local site using iBegin Source.

One of the motivating factors behind iBegin Source was to enable hobbyists (ala Kailash) to build something local. While I firmly believe that our price point is extremely affordable, it can still be expensive for others (ala Kailash - a student). So while I had never officially announced it (I imagined it would be months before it would be useful) - we had always intended on awarding ‘free’ commercial licenses to interesting projects. They would still have to link back to iBegin Source, but otherwise they would get the full commercial data/license.

Case in point: OddPath. Kailash did the entire site himself, without incurring a dime in expenses (other than hosting). And he was able to do this because of iBegin Source.

Before I digress any further - OddPath’s best feature is its mobile search. Simple and effective, I think this is OddPath’s best feature. Other features such as ‘Buzz’ and ‘Pictures’ are interesting, but definitely need some fine tuning. The mobile feature (and its simplicity) could push him forward there.