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

Andrew Ross grof at rogers.com
Thu Nov 13 19:24:48 EST 2008


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 11, 2008 11:06 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Anyone interested in geocoding and routing?

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

(Orkney)Toru Mori wrote:
> Apart from technical design, geocoder is "useless without data" :)
> 
> Address systems are varied and messy, at least here in Japan and in 
> other Asia region. For example, Japan has more than 3 systems. 
> Additionally it is very tough to get good "enough" data. There is no 
> separation in address text.
> 
> We developed geocoder.ja already for our region specifically, but 
> unfortunately it won't work in even other countries in Asia.
> http://www.postlbs.org/ja/geocoder
> 
> 
> A sigle universal, global geocoder may sound perfect. However, there 
> is very limited space in terms of standardization as follows.
> 
> -----------------------------------------
>      API (can be standardized)
> -----------------------------------------
>  thin parser (might be standardized)
> -----------------------------------------
>  geocoding logic (cannot be standardized)
> -----------------------------------------
>      local dataset (varied and messy)
> -----------------------------------------
> 
> So what OSGeo should lead would be just APIs. If OSGeo wants to 
> standardize lower levels, then the project won't finish probably.
> 
> 
> p.s. Anybody want to talk about routing?
> 
> Toru Mori
> 
> 
> "Andrew Ross" <grof at rogers.com> wrote:
>> Thank you everyone for the great response to this post.
>>  
>> I'd like to poll everyone's thoughts regarding the appropriate next 
>> steps. It seems to me we have good support for this initiative.
>>  
>> It isn't as clear to me yet what the best way forward is. My 
>> instincts are leaning towards spending time to capture requirements, 
>> identify key use cases, and crucial standards. The thinking is that 
>> with this information captured, we're in a better position to review 
>> the implementations available to identify which candidates are best 
>> positioned to satisfy those needs.
>>  
>> I would like to echo Andrew Turner's comments that we're focusing on 
>> API's that can be used offline rather than a web service. (though 
>> it's good to see great web service projects out there!)
>>  
>> Input, thoughts, feedback are greatly appreciated. Thank you in 
>> advance,
>>  
>> Andrew
>>
>>
> _______________________________________________
> 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



More information about the Routergeocoder mailing list