[pycsw-devel] Issues with the PostGIS backend + real live metadata

Angelos Tzotsos gcpp.kalxas at gmail.com
Wed Aug 21 08:02:43 PDT 2013


Hi Adria,

Thanks for the feedback.

Some comments inline:


On Wed, Aug 21, 2013 at 1:54 PM, Adrià Mercader <adria.mercader at okfn.org>wrote:

> Hi all,
>
> I've been playing around trying to set up pycsw with Postgres +
> PostGIS as backend, with mixed results. Here are a list of things I
> found:
>
>
> * If I understood the docs correctly [1], if you are using PostGIS
> (which the script will autodetect), the native PostGIS functions will
> be used and there is no need for the plpythonu functions. But if you
> call setup_db with create_plpythonu_functions=False, the geometry
> column and the trigger are not created, as they are in the same code
> block as the plpythonu functions creation.


I usually create plpythonu functions even if PostGIS is present. This way
if for some reason postgis gets unavailable in the future, pycsw will
continue to work.
But yes, you understood correctly, thanks for the fix.


> It looks like this commit
> moved the indentation one level down [2].
>
> The rest of issues that followed assumed that this was fixed (ie I can
> use PostGIS without plpythonu), but please correct me if wrong.
>
> * After setting up the wkb_geometry in this way I always got an
> IntegrityError exception when trying to load a document which has a
> bbox defined. This was easy to spot, there was a typo in the srid on
> AddGeometryColumn.
>
> This PR fixes both issues:
>
> https://github.com/geopython/pycsw/pull/177
>
>
good catch, thanks


>
> * On several documents I tried I got exceptions because the fields
> defined were too short:
>
> DataError('(DataError) value too long for type character varying(256)\n',)
>
> See eg the abstract field in [3][4] or conditionapplyingtoaccessanduse
> in [5] (you find this with much more fields once you start importing
> large numbers of records).
> I'm not a DB expert, and I certainly can't talk for sqlite, but I
> would imagine that changing the column definitions to character
> varying(x) to text would have no effect on performance while removing
> all kind of text length limit problems. This is a good resource [6]
>

+1


>
> * As a really minor general comment, the exceptions raised while
> loading documents [8] are a bit too noisy, as they output the whole
> document, making difficult to know what actually went wrong.
>

Yes this is true.


>
> Hope this helps,
>
> Adrià
>
>
Best,
Angelos




-- 
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pycsw-devel/attachments/20130821/8e07b921/attachment.html>


More information about the pycsw-devel mailing list