[postgis-tickets] [PostGIS] #2387: Include pagc_address_parser as part of PostGIS (was: Register pagc_address_standardizer as a PostgreSQL extension package)

[PostGIS]

#2387: Include pagc_address_parser as part of PostGIS
---------------------------------+------------------------------------------
 Reporter:  robe                 |       Owner:  robe         
     Type:  enhancement          |      Status:  new          
 Priority:  medium               |   Milestone:  PostGIS 2.2.0
Component:  pagc_address_parser  |     Version:  trunk        
 Keywords:                       |  
---------------------------------+------------------------------------------
Description changed by robe:

Old description:

> I was also thinking since we are at a stable essentially 1.0 point and
> the address_standardizer is now wrapped as an extension and its fairly
> light-weight (only extra dependencies on pcre stuff available on most
> Linux/Unix distros), it might be worthwhile to register it as an official
> PostgreSQL extension at
>
> http://manager.pgxn.org/
>
> Thinking about it more, since it doesn't have any direct reliance on
> PostGIS, it will probably be better served if its stands on its own since
> it has value without anything else.
>
> The other benefit is that folks on Unix/Linux can then install it using
> the pgxn client.
>
> http://pgxnclient.projects.pgfoundry.org/
>
> Then I can amend the instructions accordingly to offer this simplified
> instruction set in PostGIS docs in additiona to hte standard svn checkout
> approach.
>
> Sadly this approach doesn't work on Windows cause windows doesn't really
> support PostgreSQL make files unless you are building under Mingw. (strk
> keep your mouth shut. :) )
>

> I'll be shipping address_standardizer with the newly dubbed (PostGIS
> bundle starting at 2.1) and update our instructions accordingly   so
> doesn't matter for windows users.

New description:

 Thought about this more and since the large majority of users are PostGIS
 users, makes sense to just package it with PostGIS.  That will minimize on
 all the questions about where to file bugs and since tiger uses it might
 allow for easier build, so people don't have to compile it on their own.

 Discussed this with Steve Woodbridge and he's for the idea.  That would
 mean we'll need to give him postgis repo access.

 ----- OLD THOUGHT --
 I was also thinking since we are at a stable essentially 1.0 point and the
 address_standardizer is now wrapped as an extension and its fairly light-
 weight (only extra dependencies on pcre stuff available on most Linux/Unix
 distros), it might be worthwhile to register it as an official PostgreSQL
 extension at

 http://manager.pgxn.org/

 Thinking about it more, since it doesn't have any direct reliance on
 PostGIS, it will probably be better served if its stands on its own since
 it has value without anything else.

 The other benefit is that folks on Unix/Linux can then install it using
 the pgxn client.

 http://pgxnclient.projects.pgfoundry.org/

 Then I can amend the instructions accordingly to offer this simplified
 instruction set in PostGIS docs in additiona to hte standard svn checkout
 approach.

 Sadly this approach doesn't work on Windows cause windows doesn't really
 support PostgreSQL make files unless you are building under Mingw. (strk
 keep your mouth shut. :) )


 I'll be shipping address_standardizer with the newly dubbed (PostGIS
 bundle starting at 2.1) and update our instructions accordingly   so
 doesn't matter for windows users.

--

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2387#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.