[postgis-users] topology : statue of topogeom composition?

2015-11-12 Thread Rémi Cura
Hello everybody.
a question mostly for Sandro I'm afraid.

What is the current status of postgis topology regarding composition
between topogeometry?

First of all is it possible to have topogeometry composed of other
topogeometry, themselves composed of other geometry, and so one?

Second,
if this is possible, are this kind of topogeometry properly maintained when
there is a change in the low level topology (splitting an edge for
instance).

I think I know the answers,
but I really would like to be sure.

Thanks =)

Cheers,
Rémi
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

[postgis-users] document work-around for restore and materialized view issue

2015-11-12 Thread Regina Obe
I guess a lot of people are being bitten by this:

https://trac.osgeo.org/postgis/ticket/2485

https://lists.osgeo.org/pipermail/postgis-users/2015-November/040944.html

and it's getting kinda depressing.  Given that we can't come up with a
solution we can all agree with, I was thinking of just documenting my
general work-around fix.

BTW as mentioned, this is not just an issue affecting rster.  It also
really bites you if you use materialized views as it tries to populate
data during restore and fails.

Anywaon have an issue with me - documenting the work around in a
postgis.net tip section and a link to the tip in the FAQs?


Thanks,
Regina
http://www.postgis.us
http://postgis.net






___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

2015-11-12 Thread Regina Obe
Darrel
> On one of my databases I do get a new (presumably trivial) error:
> pg_restore: processing data for table "spatial_ref_sys"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 3303; 0 35941 TABLE
DATA > spatial_ref_sys postgres
> pg_restore: [archiver (db)] COPY failed for table "spatial_ref_sys":
> ERROR:  duplicate key value violates unique constraint
> "spatial_ref_sys_pkey"
> DETAIL:  Key (srid)=(5013) already exists.

Yes you can ignore.  It's possible for whatever reason that wasn't marked
as an exclude from backup and the data got saved but is shipped with
PostGIS.  I think pramsey came across that and fixed in 2.2.1.

At anyrate its a harmless error if your backup is stet to ignore errors
which is the default.

Thanks,
Regina



___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

[postgis-users] restore problem

2015-11-12 Thread Darrel Maddy
OK trying this again without the prior messages to avoid the max limits.

Apologies if my original appears, when I tried to cancel the posting it seemed 
to ask for a ‘cookie’ code I did not have!

Anyhow, thanks to everyone.

D

From: Darrel Maddy
Sent: 12 November 2015 09:51
To: PostGIS Users Discussion 
Subject: RE: [postgis-users] restore problem

Dear  Regina,

Many thanks again for this detailed explanation – this really does help me 
understand what is happening.  I did not have the clean flag set BUT when I 
tried this again this morning it has worked ☺. I have tried this on two 
databases now and both seem to have restored the raster data. Clearly I would 
not have figured this out without your instruction! It is a shame that this 
process is not as easy as I am sure everyone would like it to be but the 
workaround is simple once you know how and as long as this is documented I 
don’t see this as a deal breaker.

On one of my databases I do get a new (presumably trivial) error:
pg_restore: processing data for table "spatial_ref_sys"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3303; 0 35941 TABLE DATA 
spatial_ref_sys postgres
pg_restore: [archiver (db)] COPY failed for table "spatial_ref_sys": ERROR:  
duplicate key value violates unique constraint "spatial_ref_sys_pkey"
DETAIL:  Key (srid)=(5013) already exists.

This only happened on the second database I tried to restore and it may not be 
a significant issue. Should I ignore this?

Many thanks again from a very relieved

Darrel


___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users