[postgis-devel] PAGC Address Standardizer some thoughtsonhowtoorganize

Stephen Woodbridge woodbri at swoodbridge.com
Wed Aug 6 12:47:58 PDT 2014


On 8/6/2014 3:30 PM, Paragon Corporation wrote:
> Steve,
>
> Forgot to ask one thing:
>
> Regarding the data extension idea, am I correct in assuming that the  cpan
> Regexp::Assemble
>
> Is only needed to build the lex,gaz, and rules files?

No lex, gaz and rules do not use this.

Regexp::Assemble is used to build parseaddress-stcities.h and 
parseaddress-regex.h from the data files usps-st-city-name.txt, 
usps-st-city-orig.txt, and usps-st-city-adds.txt.

These are used by the one line address parser. if you ship over the .h 
files then you don't need to recreate them. The only time we would need 
to fiddle with them is if we are trying to fix a bug in the single line 
parser. I'm hoping that at some point we can get Walter to replace the 
single line parser with code that uses lex, gaz and rules.

> If so what I want to do is just have debbie build these and include as part
> of the tar ball already built.
> People can then conditionally build these if they are pulling from svn but
> won't be required if building from tar ball.

You should be able to just ship over the parseaddress-stcities.h and 
parseaddress-regex.h files and avoid the build dependency.

-Steve

> That would be one less dependency I have to check (which I have no idea how
> to check with configure)
>
> And then we can just build the address_standardizer if pcre extension is
> found or included with the --include... Or
> --with--whatever-convention-pramsey-decides
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at lists.osgeo.org
> [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paragon
> Corporation
> Sent: Wednesday, August 06, 2014 3:17 PM
> To: 'PostGIS Development Discussion'
> Subject: Re: [postgis-devel] PAGC Address Standardizer some
> thoughtsonhowtoorganize
>
>
> Steve,
>> Hi Regina,
>
>> I'm fine with this.
>> I'm ok, with not supporting 9.0
>
>> So when all is said and done we will be able to:
>
>> CREATE EXTENSION address_standardizer;
> Yes
>
>> Are you still planning to have the lex, gaz and rules data installable
>> via
> a .sql file so people can load and modify the tables as they might need?
> Debating on this.  I was still thinking it would be nicer to have this
> wrapped as a data extension for ease of install rather than stand-alone sql
> files.
> People can then bulk copy the records to new tables if they want to further
> customize or use as is.  I guess there is no reason we can't have it both
> ways (as raw sql and data extensions)
>
>
>
>> When you install postgis_tiger_geocoder that will install the
> address_standardizer and it's own private lex, gaz, and rules tables. Is
> this correct? Or will you just postgis_tiger_geocoder dependent on the
> address_standardizer extension?
>
> Right now tiger already has its own private set of lex,gaz, and rules.  It
> is currently set to work with or without address_standardizer as a
> requirement.  Eventually I will make it a requirement once
> address_standardizer is completely incorporated into PostGIS configure
> scripts, I've stress tested it, and I feel confident all distros carrying
> PostGIS 2.2 will not have issue building it.
>
>
> Thanks,
>    Regina
>
>
> On 8/6/2014 12:03 AM, Paragon Corporation wrote:
>>
>>
>>>>>>
>>>>>> 1) Create folder in extensions of our repo and move the
>>>>> address_standardizer extension files to their I'd still like it to
>>>>> be able to be built separately if people wish (similar to how we
>>>>> have liblwgeom I think) and my only reservation with breaking out
>>>>> like this is that it makes it less compact.
>>
>>
>>> I would defer to strk on this, but can we use a symlink to get the
>>> file to appear in two places under svn?
>>
>>> Let's stay away from symlinks - they don't behave well under windows.
>>> I
>> think for now we'll Just leave the extension files wher they are and
>> decide what to do later.
>>> Perhaps just copy the control files as part of our extension make
> scripts.
>>
>>> I was the one who started the extension folder primarily because when
>>> I
>> was formulating the extension install Process, it was easier not to
>> affect the rest of the code base while I was fleshing things out.
>>
>>> That said the only issue is the documentation auto comments
>>> generation
>> that I would like address_standardizer to Have similar to the other
>> extensions we have.  As well as the versioning plumming that all
>> postgis extensions share.
>>
>>
>>> Let's see how things go keeping things where they are unless someone
>>> has a better idea.
>>
>>
>> Just an update on this thread.  In working thru the logistics of
>> folding in address_standardizer into our configure scripts, I've
>> decided to just move all of address_standardizer code into the
>> extensions folder and out of extras
>>
>> So instead of it being in
>>
>> Extras\address_standardizer
>>
>>
>>
>> It will be ONLY be in
>>
>> extensions\address_standardizer
>>
>>
>> The reason for this is after I was fiddling with the make file to make
>> it use the same machinery as the rest of our code base and our
>> extension versioning there was really nothing left in the makefile.
>>
>> This avoids the whole whether to copy stuff to extensions or symlink.
>>
>> Also in PostGIS 2.2, we no longer support PostgreSQL 9.0.  That said,
>> there is no reason why anyone should be installing
>> address_standardizer without using CREATE EXTENSION
>>
>> Let me know if anyone has objection to this before I move forward with
>> this change.
>>
>> Thanks,
>> Regina
>>
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>




More information about the postgis-devel mailing list