First I want to thank Linda and Mike for inviting me, and I want to thank Steve Smyth for not showing up. I came here to learn really, more than to make a presentation. I wasn't on the agenda, I had worked up some things for last night, but I'm kind of awed both by the quantity and quality of the people that are here, the quantity and quality of the organizations represented. Certainly the quantity - maybe we're here to figure out what the quality really is of the quantity of the data that we're trying to deal with. Go2 is a brainchild of mine which I started in 1995. I was a pilot, I knew where GPS was going, I could see that the kind of location technology that was provided by GPS was going to become common to the average person, and yet I knew that in flying we never used latitude and longitude because it was confusing. There was a much simpler system that was in place, and I thought to myself, can't we come up with a better system for the average guy on the street to use for geo-referencing and trying to find things that are important to him or her? I hooked up with Peter Dana at the University of Texas, and he and I collectively over the course of a year and a half or two put together something we now call the Go2 System, or WGRS.
Basically our idea with Go2 is to come up with a simple user interface between the average person and geographic information. Primarily with respect to the Internet, also with respect to cellular telephones, portable computers, any kind of moveable device, car navigation systems. The premise was that latitude and longitude was not the right answer because it's relatively confusing. As I've learned over the past few years, there are lots of different formats for latitude and longitude, different data and different ways. That's one of the problems - if you're not speaking exactly the same language when you say latitude and longitude, and know exactly what format - or you're trying to input a lat line that someone else has given you verbally into a device that's structured in a different format, it's relatively difficult. If you imagine the 7 year old working on a cellular phone when his father's had a heart attack, trying to describe what the phone says in terms of where he is, because phones will be location-enabled in a couple of years. Our view is that this universal Go2 address could be very helpful.
There are two objectives with Go2 - by the way, I should give you a little background data and I should also say this, my PowerPoint was not prepared for this group.I threw it together this morning when I realized that Steve Smyth wasn't going to be here. This is what we use mostly as we go around and talk to people who are trying to hook up with strategic partners and to try to develop the system, but there are some interesting things here that I think are worthy of note for this group.
There are going to be over a billion cell phones in use by 2004. They won't all be location-enabled, but if you're familiar with the SEC mandate, you'll know that by October 1, 2001, when you dial 911 on your cellular phone, they're supposed to know where you are within a hundred meters in the U.S. and that technology is coming. So our view was, let's take that technology and find a way for the average person to use it. I think it relates to gazetteers perhaps at a lower level, but people that are using these cellular phones are going to be looking for perhaps the closest McDonalds or pizza emergency, as someone referred to earlier, but they'll also be looking for points of interest in the Grand Canyon National Park or Great Glacier National Park. They may be looking for some of the data we've talked about today, but in many cases it might be at a lower level. It's more when you want to find things close to you, it may be the hospital, it may be food, whatever.
A couple of people that are working with us in the geography arena, because I'm not a geographer by training: Dr. Clark at UCSB, a colleague of Mike Goodchild, is on our scientific advisory board - he's worked with us and given us great advice; Reg Golledge also at UCSB; Peter Dana I mentioned earlier; and Jordan Hastings, Ph D candidate at UCSB. I'm from Southern California if you can't tell, so I have access to a lot of people from UCSB, but they've given us a lot of good advice and helped us a lot along the way. I haven’t worked with Scott before but we've been working with ESRI on this project, and they have given us some conceptual approvals and expressed a strong interest in embedding some of Go2 into some of their software.
The two key components of Go2: one is the universal address, which I won't spend too much time on but it's a hierarchically structured address. It looks a lot like a URL: we designed it that way because we think the average person has some familiarity now with URLs. You can see it's a relatively simple structure, we will have a naming convention, it will perhaps not be critical for us but it will be important for us for that naming convention to be static. We'll be able to parse to a certain extent, we can provide the full name if that's what people want, but our idea was to try to come up with something that was very compact for use with the cellular phone or some other portable device. If you're driving your car, you want to be able to input LA as quickly as possible and not have to spell out Los Angeles.
Obviously GPS devices, the cell phone, they will know where they are, so in many cases you would never input US or CA. You probably wouldn't even have to input NB in this case, unless you happened to be in an adjacent city and wanted to designate Newport Beach. The grid that we've come up with after a lot of work and effort is a hundred kilometer square - that will allow us to give 10 meter precision with 8 digits. If you want one meter precision, you can add two more digits. Because it's hierarchical, if you happen to be working in an area - say Disneyland, for example - if it's all in the Newport Beach 1234 aerial grid, then references in and amongst the people of Disneyland could truncate the higher level and simply say we're at 5678 for security guards or people parking their car or whatever. We're going to work with this user interface to make sure it works right.
The second piece of the Go2 system as we're proposing it uses the same addressing convention to the point that it gets you to a city, in this case Newport Beach. At that point it becomes a place name registration process, a lot like domain names on the Internet. Again we think maybe the average person will understand this because they've seen what domain names are, they see how a domain name will get them to a particular spot on the Internet. Our view is they can use that same structure to find whatever it is they're looking for in the real world; so if it's IHOP or McDonalds or a particular mall, whatever - if it's the entrance to the Grand Canyon - our view is that perhaps some day maps might have the little Go2 identifier there, much the same way as you have all the VORs in all the airports listed on navigation maps with a little identifier. Again eventually maybe people will move to voice recognition; this won't be so critical, we actually think maybe we facilitate that because we try to create somewhat of a standard.
There is now a GPS watch on the market made by Casio. I haven't seen it; my guess is that it tells you where you are in latitude and longitude. I have no idea how you input the latitude and longitude if you're trying to navigate to a particular location. But these are the kinds of things that we're trying to make, if you will, Go2-enabled, which is our plan to make people identify this name and identify that if it's Go2-enabled you can use this addressing system. We are writing for WAP phones, and this is just a simple example.
We think there are three things that people will do from phones: when they don't know what they want, they'll try to find it - they want burgers, they want pizza, they want a hotel - and that's the Go2 search idea. If they know exactly where they want to go - they want to go to the Holiday Inn at the airport, and they're already in the Baltimore area, they will hopefully remember that HI is Holiday Inn. Somehow they'll designate airport, we haven't quite figured that out yet, and they can hit the button and it will now communicate an intended destination. The user won't have to go through a whole series of menus.
Then there is the "Where am I?" situation, which is the 911 issue - "I'm in an emergency, I need to tell someone right now exactly where I am." How do I do that? Interestingly enough, for the first couple of years, the people that we're working with that are making the phones and are working on the interfaces want to use the Where am I? so that the user can tell the phone where the user is, because the phone's not going to have that capability for a couple of years. And obviously if you're trying to serve up location-relevant information to someone, you need to know where they are.
We have a piece of software which we hope will be downloadable free over the Internet, and it will provide a location handshake to any website, so it will go into your laptop. It will work much the same way as your cell phone, and it will in essence provide a location handshake. It's not a cookie; it's something different. So that any website that you hit that is Go2-enabled, that had the little software that we have, would now know essentially where you are and would be able to serve up location-relevant information.
We talked about the placename concept. I think that's the most relevant for this group because many of the issues that you're dealing with are issues that we will have to deal with - to try to make the naming convention usable, try to minimize errors and primarily make it user-friendly. We have the concept of a Go2-prefix, so you could put Go2 dot in front of any website and if you're Go2-enabled, that website would now know where you are, it could then say OK, here's the appropriate map on how to get here, it could serve up location-relevant information.
We have a concept of a site map that I'll mention now - I have an example later with the place name registered like a domain name. It could be linked to a site map, a site map as a specific map, not computer-generated, but it provides information like hours of operations, here's the best place to park before 5 o'clock, here's the best place to park after 5 o'clock, any kind of information totally controlled by the destination, if you will. You can park on the street until 4.30 but after that you'd better move your car, that's the kind of detail you can provide over the Internet which you could never have provided before.
We have universal Go2 addresses. We are primarily making this for electronic devices over the Internet and we're definitely working on paper map integration. We haven't done it yet, but we're going to try to find a way to make sure the people that want to work with paper maps can do so, and that there would be interoperability between paper maps and this electronic system.
The structure is hierarchical, and we think that provides some advantages over latitude and longitude in terms of both data storage, in that it takes up less space, and there may be some rapid searching that we can do because everything is hierarchically structured. We also think it definitely simplifies data storage at a small scale. If you're working in the city of Newport Beach, you really don't care about anything outside of Newport Beach - if you're the police department or whatever, or certainly outside of 42 miles or roughly that from Newport Beach. So really you don't ever have to maintain your database US, CA and NB. You just keep an 8-digit integer that gives you 10-meter precision. I think one key here is the 911. We've talked to people in the industry and they're very nervous. Somebody mentioned earlier that all the wire lines are geo-coded, and they are, but right now in the US there are over 100,000 911 calls a day from wireless telephones and they have no idea where these people are. That's one reason why they had this FCC mandate, and we think in that arena this system we're proposing will perhaps be easier to use, and will allow that 7 year old to accurately read his location or communicate to someone, and that might make a difference in an emergency situation.
A lot of those transmissions will be electronic, in which case our system doesn't make any difference, but our view is that unless every transmission - from the emergency to the telephone company all the way through to the ambulance driver and the AAA company - unless every transmission is electronic, the ability to quickly and efficiently identify that location in the way that will cause the least probability of error will be important. Remember you're trying to input this location into an electronic device, there has to be a keypad of some kind, it might be a full keyboard, in many cases it won't be, so we think the number system has some advantages there.
One of the issues that we've had to deal with - it's obvious and I know that many of the people in this audience will look at this and have probably already figured this out - we do have overlapping grids. Our grids are assigned based on population centers, so that we have for example roughly 100 grids in California at the higher level, and there is some overlap there, but it does completely cover the state, and because they're based on population centers, it's fairly unlikely that you're going to be at the intersection of two grids and so you can almost always navigate in and around an area by one grid. You could also geo-reference in this, although again I don't know if that's the best use of WGRS or not. We're working on that now.
Each pair of digits in our notation refers to an increasingly more precise area, and they are areal references. There are over a dozen different formats for latitude and longitude.I'm sure that many of you have worked with many of them. Lat/long is good but it's not very user-friendly. We've looked at other geo-coordinate systems also. People say what about street addresses? We're not trying to replace them; we're not trying to replace lat/long. All we're saying is that the average person on the street could use a slightly better referencing system.
We think a sheriff for example could input the Go2 address in numeric format, and then it could geo-reference into his database that he might have on board and could provide him the full street address right there - as he's driving down the road he would not have to input the full street address.
We've looked at the gazetteer data that's out there, for example the traditional Yellow Pages databases. It’s not very good data. It's the same issue that you all deal with on a daily basis. I'm sure data gets old and it doesn't get updated. We are going to the vendors and saying, we will improve your data and we will assign this name and we will make sure that yellow up on top is better data.
We also think that we can help people find what is close to them. For example, I was looking for a piano teacher for my daughter in my immediate neighborhood. She had to ride her bike or she couldn't go because our schedules just didn't permit driving her somewhere. Our vision with Go2 is that people at that level will be able to register for free, they'll be on the Internet and everything would be geo-coded, so when I get on the Net from my house and hit Go2_piano_lessons.com, up would come the closest piano teachers. We are an Internet company. We are opening up a website in probably a month or so, we're a little bit like Allen, we're working furiously to try to make it work right before we turn it on and let people see it. We have a main website, Go2online, and then we have about a thousand other websites with various topics. The reason I'm here is to learn about the problems that you all have had with gazetteers and to see how Go2 might help in some respect, perhaps on the technical side but also from the standpoint that we are trying to bring this geographic information to that average guy on the street, and we think that the Internet is an amazing tool for that - the interoperability, the availability of all the databases now that will be available to you from your cell phone is pretty amazing. I don't know if you're going to use that for heavy hard-core research, but you probably will use it if you're in the Grand Canyon, perhaps trying to find the parking lot for Plateau Point.
Go2 is a proprietary system, but we're going to open source the bulk of it. Our plan is to see if it has value, and if it does have value to the geographic community we want to make it available at the lowest possible price, and probably free in many cases. We're going to be venture-backed eventually, so we have to have a model that makes sense, but on the universal side of it we're motivated by a desire to have it out there available for 911. We think that the funding mechanism will come from the McDonalds of the world, who have a keen interest in driving business through their front door. But the whole concept behind Go2 was - how can we make geo-referencing easy so that people will use it, because I personally believe that if you gave somebody a hand-held GPS device, and they were trying to navigate to Bakersfield and wanted to keep track of their time and distance and how much further they had to go, they were not going to do it if in order to use that device they had to go look up the latitude and longitude of Bakersfield. But they would do it if it was real easy and they could put in Bkf at the time.
Some of the devices now have those gazetteers with cities and so it
is easier to use, but that was the whole plan. So that's my quick presentation,
I really thank you for your time and patience on this and I'm happy to
answer any questions.