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

[Stephen Woodbridge]

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