[postgis-devel] PAGC Address Standardizer some thoughts onhowtoorganize

[Stephen Woodbridge]

On 8/6/2014 3:17 PM, Paragon Corporation wrote:
>
> 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)

Regina,

I like the simplicity of install as extension and use as is, or copy the 
data to your private tables and modify it. This makes a lot of sense to 
me from a usability point of view and a maintenance/documentation point 
of view also.

-Steve

>> 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
>