Auto-completing geoinformation service

When I started to look into the theme of open source and contributing to the IT world, I had thought about really useful program or library, but after that I decided that it will be waste of time. Taking into account my life style, I won't support this project after some initial time and it will be broken as many other infamous attempts (we can even look on strange life cycle of a great product of Google - Google Wave, that ended after two months in production).
My goal is to provide a small kernel, full cycle of supporting and development of this project without deeply digging into the subject. My choice has become a service. You can ask what the logical difference between producing a program and service? From the program code point of view it is the same operators and conditions, but they give different results to the end user and according to the type of service they can meant for really different end users. Service provides some additional capabilities and very often expands another program product. From the another side, program is completed product that helps end user to do some actions and receive expected results. Of course all my previous thoughts are nothing but philosophy, and they had been running through my head.

Now, let's look into the main goal of this service and why I have chosen exactly this type of service. I want to share useful and commonly used part or subsystem and help developers to make the part of the program faster. What do we see in all types of programs and interfaces? My idea is that it's geoinformation data. Obviously we have systems that don't use any geoinformation and give us great value without it, but the number of program products use it in different approaches and structures.

So, now we have two main questions: will the geoinformational service be used and what type of service will it be?

We can divide it using different criterias, but I will look at three of them: detalisation, validity and sources of retrieving.
By detalisation that is often uses we mean coordinates using longitude and latitude, up to street and house, up to flat and up to city.
Under validity I mean - compliance with the real naming, object hierarchy or privacy and policy.
Sources are in many cases databases that consist of dictionaries or hierarchy structures of objects and places associated with them. Many additional information could be attached to geo objects. These databases could be local, distributed or service oriented. Services provide some API for information search and give quick answer to your problem, they can be filled with data and supported on demand or in contract way. Service takes care of all details of storing these big amounts of information maintenance and accessibility. So we come to the concept of SaaS, that have got new breath after fast growth cloud technologies and especially services.
Next, I will concentrate on implementing simple, lightweight geo web service, with detalisation up to city, that will use RESTfull interface or standard SOAP interface for communication with the clients.
My service will provide simple information:

• list of all countries in the Earth (with future plans to support new Moon's settlements)
• list of all cities in specified country
• additional information about states, provinces, districts or regions and also list of the corresponding cities
• autocomplete tips that help to input information and names.

In my case I will use different heterogeneous sources like free databases, subqueries to web mapping services and collect any feedback from consumers or clients. May be I will implement self education module, that will try to collect data from queries and add unknown information to the local information storage.
I chose so high detalisation level because of the lack of big resources storing bigger amount of information, and of course because of growing complexity of the service with growing of detalisation level.

Some technical notes, I plan to use .NET platform, MS SQL Server, WCF, git and some library for creating REST interface. Right now I see three candidates RestMvc, RestCake or Simply Restful Routing from the MvcContrib.

I will notify in next post about details and process of contributing and organization of this project.

All feedback and participating is welcome!