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

[Andrew Ross]

FWD for history on the new list 

-----Original Message-----
From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
Sent: November 12, 2008 11:00 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Anyone interested in geocoding and routing?

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

_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss