Leo and Regina,
Thanks for the tips. To follow up, I ended up going in a slightly
different direction, as I really wanted the whole segment from one
intersection to another, not just the intersection point.
My method relies more on regexes than yours, but I also have the
advantage that I'm only trying to geocode one data source, not any
random address.
Unfortunately, my source data is even less consistent than the
census in how it treats abbreviations! I'm getting about 70% match
rate, and will have to do the rest by process of elimination I think.
One thing that might help your effort is I did a quick translation of
the abbreviations pdf into a csv document. I can post it to github or
attach it to the bug report if you are interested. I use it by testing
for both the full name and any possible abbreviations in the regex
compare.
Regards,
James
On Thu, Sep 27, 2012 at 04:20:41PM -0400, Paragon Corporation wrote:
>
> James,
> Which version are you using? I assume the 2.1.0SVN one?
>
> That we can probably change the structure of a bit since it hasn't been
> released yet and can probalby get away with change the norm_addy type as
> well which we've been dragging our feet on a bit
> Mostly because it brings along a bunch of upgrade issues we'd need to
> provide for people using tiger already.
>
> If you look at the file
>
> tiger_2011\tables\lookup_tables_2011.sql
>
> The street_type_lookup values is what controls how Camino is treated.
>
> That probably will require another field at some point we are guessing to
> better follow the Tiger Feature name types convention of Prefix Type /
> Suffix type (and possibly Spanish column) they document in
>
> http://www.census.gov/geo/www/tiger/tgrshp2011/TGRSHP2011_TechDoc_E.pdf
>
> I think we are missing a bunch too. Haven't bothered reconciling their list
> with what we have.
>
> That's probably a good start. The normalize_address function itself is
> kinda scary to looku at but you can if you want. We were hoping to
> modularize it a bit more later.
>
>
> Hope that helps,
> Leo and Regina
> http://www.postgis.us
>
>
>
> -Original Message-
> From: postgis-users-boun...@postgis.refractions.net
> [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of James
> Marca
> Sent: Thursday, September 27, 2012 4:06 PM
> To: 'PostGIS Users Discussion'
> Subject: Re: [postgis-users] Tiger geocoder,Spanish street types are pushed
> to the end
>
> On Thu, Sep 27, 2012 at 03:56:53PM -0400, Paragon Corporation wrote:
> > James,
> >
> > Sadly this is a known issue and one we haven't settled on the best way
> > to fix without resorting to major surgery.
>
> oops, my bad. I forgot to look at the open tickets.
>
> >
> > Here is the ticket for it:
> >
> > http://trac.osgeo.org/postgis/ticket/1118
> >
> > If you can add your examples to the ticket and add yourself to cc for
> > the ticket that would be great. We'll add these to our regress tests
> > when we finally come up with a palpable fix.
>
> I'll do it now
>
> >
> >
> > In MA we have similar issues, but mostly with french streets locally
> > they are a rare occurrence, but Leo feels your pain about Cali since
> > he's a San Diego boy.
>
> I was going to say this might be a problem in other countries, but, duh,
> Tiger is US-only.
>
> >
> > Sorry we couldn't be more helpful.
>
> I'm a reasonably competent hacker, so if you point me at the right
> file(s) I'd be happy to try my hand.
>
> Regards,
> James
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
pgpVopk4CScWq.pgp
Description: PGP signature
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
