[OSGeo-Discuss] Anyone interested in geocoding and routing?

[(Orkney)Toru Mori]

Steve,

I totally agree to your opinion. We can have a standard framework and we 
may call it "OSgeo international geocoding framework", not "geocoder".

Everybody would love concept of GDAL/OGR, however, geocoder will have 
deferent story.

In my experience of working for a U.S. based GIS company which has global 
operations, an international geocoder was always requested by customers. 
The company developed geocoders of U.S., Canada, England, Western part of 
Europe and Australia. However, they are not really unified. Even they have 
similar address systems, the U.S. engine couldn't handle other regions 
instantly.

Regarding Japan, Korea and China, they have unique address systems each, 
so even normalization of inbound address data process did not work with 
one algorithm. Geocoder always works with data. Address data and system 
are made based on each local culture and history.

I won't discourage that we try to have an open geocoder at all.
Just want to avoid possible misunderstanding on this list that "i18n" 
geocoder can be a snap.

Mori

Stephen Woodbridge <woodbri at swoodbridge.com> wrote：
> Yes, you are correct, but this is not a reason for not trying. For
> example, US, Canada, and most (all?) of Europe could be represented by a
> single engine. It is likely, that large chunks of the rest of the world
> can be represented by a similar engine, and then there will be a bunch
> of exceptions, like those you reference in Asia.
> 
> It seems to me that if you scan the in coming request you should be able
> to guess the country or identify it as part of the request and load the
> engine/data to support it, if it is supported, and go from there.
> 
> Data is always a problem. That is one of the reasons that I think a SQL
> backing store is required. Each data set would need to be mapped and
> standardized to a standard schema that is supported by one of the
> geocoder engines. Data would need to be converted from its raw format
> and standardized into the standard schema.
> 
> So beyond the API, we would have some representative geocoder engines
> and specific data loaders targeted at specific data sets, and data
> standardizers targeted at specific countries.
> 
> If we take a modular approach of using plugins, then we can design an
> API, design the plugin API, design some of the data standards, and make
> reference implementations. This will allow the project to work with many
> people that have specific data/country needs that can build into the
> framework.
> 
> I do not expect to have a one size fits all solution, I just think we
> can have a standard framework that any solution can fit into and from
> that we can have lots of collaborators working on it. I think of this
> like OpenStreetMap when it first started. I thought to myself that this
> is crazy it will never work, there are too many roads, etc. Today they
> have an impressive collection of spatial data. This is a huge task, but
> it can be tackled one step at a time.
> 
> -Steve
>