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

[Stephen Woodbridge]

Toru Mori,

Your experience with geocoders seems to be very broad and your input on
constructing a new tool will be very valuable. I have never and probably
will never work with Asian address systems because I can not read the
languages. I have written and maintained 3-4 other geocoders mostly
oriented toward US, Canada, Europe. I also have a lot of experience
working with the Oracle Spatial geocoder which handled all of US,
Canada, and England and most of Western Europe very well using a single
engine.

By the way, the geocoders do not all have to fit into the same data
structures or tables (assuming SQL). I would also not assume that
addresses have to be in street ranges, in fact some places have all
houses identified by a point. TeleAtlas data has a combination of
address ranges, and exceptions to the ranges.

The framework should provide structure for the various efforts, and
maybe provide standard services that many of the plugins can use but it
should not get in the way. For example if you do not want your addresses
standardized then you would install the do_not_mess_with_my_data
standardizer.

Someone mentioned in another post (that I can't find at the moment),
that a lot of the work will be pre-processing the raw data to load it,
this is true. The pre-processing is to standardize the data before it is
loaded, so when you standardize an input request, you have a better
chance of matching it. But you obviously should use the same
standardizer in both cases, so data loading design can not be done
separately from the overall design of an individual engine and the
country standardization tools. Once an engine has been designed, it is
possible to write data loaders for various different datasets that can
be serviced by a given engine.

I look forward to your input, experience and lessons learned.

-Steve

(Orkney)Toru Mori wrote:
> 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
>>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss