[postgis-devel] PAGC Address Standardizer some thoughts onhowtoorganize

[Paragon Corporation]

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