[RouterGeocoder] Re: [Pagc-devel] Comments re. Requirements
outlined on OSGeo
Dave McIlhagga
dmcilhagga at dmsolutions.ca
Thu Nov 27 09:07:25 EST 2008
Hi Dan, Bobb,
Apologies for the cross-posting -- but I thought this might be of
interest to the folks who recently signed up for the osgeo routing/
geocoding mailing list and might not have been following these recent
discussions.
Thanks for this info - it was exactly the background I was looking for
without having to spend way too much time with Google. :)
Re. your question about sample datasets -- as a Navteq partner, we
have access to 78 countries worth of geocodable data, so that is
certainly a good opportunity. Obviously as a proprietary dataset, we
have to take a lot of care in terms of handling this -- however within
the confines of our Navteq licensing - I'm sure we would be able to
provide useful advice into the development process and of course
testing of technology.
Re. the second point (backend-neutral) -- as long as there is no
fundamental reason the abstraction could not be completed -- I think
there are a few means of getting this done. Not to speak out of turn
-- but to a certain extent, this discussion got started in part by
Ingres' desire to have geocoding & routing solutions as part of their
upcoming spatial database support. In my discussions with them -- I
encouraged them to take this on in a way that leverages and
contributes as much as possible to the open source geospatial
community -- and here we are at this point. If the stars align -- I
suspect Ingres might be willing to take a pretty strong leadership
role in terms of enabling the back-end neutrality aspect.
All of this of course is purely speculative at the moment - pending
various folks comfort on jumping on board with PAGC. The license
change will help in this respect, and in these brief discussions a
good 'cultural' fit feels like it might exist. The one big element
that remains is some technical due diligence by a few folks before I
could imagine some bigger commitments can be made.
Dave
Dave McIlhagga
www.dmsolutions.ca
On 26-Nov-08, at 8:39 PM, Dan Putler wrote:
> Hi Dave,
>
> This is a long response, and Walter will likely add to and clarify
> these
> comments later this evening. Frank W. may also have some opinions as
> well for things related to the issue of different back-ends.
>
> PAGC has always been designed to be extensible with respect to locale,
> within limits. Specifically, this means to areas where "house" numbers
> are assigned in a spatially sequential order. PAGC has three settings
> files that can be customized to different countries. They are the
> lexicon.csv, gazeteer.csv, and rules.txt files. Through manipulation
> of
> these files, PAGC can be easily adapted for a number of areas
> outside of
> the US and Canada. Having said this, we have only worked with US and
> Canadian data up to this point because we have never gotten our
> hands on
> address ranged road network files from outside of Canada and the US.
> We
> have used it with different US and Canadian road network files (for
> Canada the StatsCan RNF and the DMTI CanMap files, and for the US
> shapefiles of TIGER/Line data and the MetroGIS data for the
> Minneapolis
> and St. Paul metro area). Our belief is that altering the gazteer.csv
> and lexicon.csv, and rules.txt files will allow PAGC to handle the
> address system of many (most?) western countries. However, the only
> way
> to know this for sure is to work with road networks from different
> western countries. To that end, do you have any we can get our hands
> on?
>
> Once you move to Asian countries, things get complicated. We know that
> in Japan house numbers along a street are assigned chronologically
> rather than spatially, as a result the standard algorithms for
> locating
> an address along a blockface breakdown. What is in PAGC (starting with
> v0.1.4) that could be the basis for a geocoder in Japan (and perhaps
> other Asian countries) is the parcel geocoder that is now part of
> PAGC.
> However, whether this would work as a solution is largely
> speculation on
> my part, and could well be wrong.
>
> A related issue would be the use of PAGC against Open Street Map data,
> which presently has no address range tags. I think (but have yet to
> investigate this) is that the new intersection geocoder in PAGC would
> allow for intersection geocoding with Open Street Map data.
>
> The upshot of all of this is that the answer to your first question is
> yes, to a certain (we think fairly large) extent. As has already
> come up
> on the RouterGeocoder list, it is unlikely that any single geocoder
> will
> handle all countries. However, we think PAGC represents a large step
> in
> this direction.
>
> In terms of "backends," I assume you mean the use of different types
> of
> data stores (e.g., PostGIS databases, MapInfo Tab and Miff files,
> and so
> on). The answer at the present moment is no. At this point PAGC is
> shapefile centric. However, in many situations this is probably less
> of
> an issue than it would first appear since OGR can be used to convert
> data from most of the commonly used back-ends to shapefile format,
> which
> can then be fed to PAGC. Not an elegant, or fast solution, but an
> often
> workable one. In many production settings, you would want to process
> all
> the road network data for geocoding prior to actually doing any
> geocoding, rather than attempt to process the road network data on the
> fly in order to respond to a geocoding query. In this type of
> production
> environment, I don't think the fact that PAGC is shapefile centric
> would
> be a major difficulty. We have discussed abstracting the data store in
> PAGC (which can be done), but implementing this would be a lot of
> work,
> and, to be blunt, we would need project sponsors to fund this
> development work to have it happen in the relatively near future.
>
> Dan
>
> On Wed, 2008-11-26 at 16:41 -0500, Dave McIlhagga wrote:
>> Dan, or others,
>>
>> Would someone be able to comment on how amenable PAGC is to the
>> design
>> requirements found on:
>>
>> http://wiki.osgeo.org/wiki/OpenGeocoder
>>
>> In particular the idea of having a pluggable architecture for
>> international geocoding schemes, and multiple back-ends? This would
>> probably help some of the folks who are just now looking at PAGC as a
>> potential baseline for meeting these needs.
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Pagc-devel mailing list
>> Pagc-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
> --
> Dan Putler
> Sauder School of Business
> University of British Columbia
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Pagc-devel mailing list
> Pagc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pagc-devel
More information about the Routergeocoder
mailing list