[postgis-users] PostGIS over distributed worksites

[Burgholzer, Robert (DEQ)]

Yeah Lee - that's a good point, though a non-static but DNS'able address might do the trick?
________________________________________
From: postgis-users [postgis-users-bounces at lists.osgeo.org] on behalf of Lee Hachadoorian [Lee.Hachadoorian+L at gmail.com]
Sent: Monday, March 07, 2016 4:09 PM
To: postgis-users at lists.osgeo.org
Subject: Re: [postgis-users] PostGIS over distributed worksites

Robert,

Meaning that you also have to maintain a Mapserver web server with
static IP? If so, it is probably not the right solution for this
project, but worth keeping in mind. Thanks for the suggestion.

Best,
--Lee

On 03/07/2016 07:27 AM, Burgholzer, Robert (DEQ) wrote:
> As Roxanne noted, the solution may vary greatly depending on whether or not you want Read-Only or Read-Write.
>
> One method I have used for read-only with QGis (and Arc*) is Mapserver providing WFS -- it may be that MapBox could also serve this?  AFAIR the Arc stations would check for updates, though conectivity would sometimes be finicky.
>
> Just a little splash of random thoughts...
>
> ________________________________________
> From: postgis-users [postgis-users-bounces at lists.osgeo.org] on behalf of rox [rox at tara-lu.com]
> Sent: Sunday, March 06, 2016 11:50 PM
> To: postgis-users at lists.osgeo.org
> Subject: Re: [postgis-users] PostGIS over distributed worksites
>
> I'm not sure what portions / parts of your db are shared or vary on a
> per seat basis, and this isn't my normal area of mucking... but I'll
> throw some ideas out and let other people improve them :)
>
> What if you set up a master database - perhaps AWS.  Set each
> distributed seat to replicate down.  Updates are pushed to the master by
> someone, and each distributed seat is auto-updated.
>
> What won't work with a pure replicated server instance.. is local
> changes, if you have them.... and so again - not my area of playing, but
> what about two local databases?  One local for changes, and a second
> that is pure replication.
> That complicates your connection configuration and potentially your tool
> interactions....
>
> Otherwise, as I understand it, barman can create a backup of one
> instance and restore the full working database to another site - so you
> could create a shared barman replication service where individual seats
> could recover a master DB when updates are required.
>
> just some thoughts to stir the discussion.
>
> Roxanne
>
> On 3/6/2016 7:21 PM, Lee Hachadoorian wrote:
>> I usually use PostGIS in a localhost or a LAN setting, where I or my
>> workgroup can all be connected to the database all the time.
>>
>> I recently set up a QGIS project using SpatiaLite with Dropbox
>> syncing, because project participants were at multiple worksites.
>> However, rendering--particularly rendering of QueryLayers--is quite
>> slow, and QGIS often crashes. Testing shows that QGIS is much more
>> responsive with PostGIS as the back end, and although it's difficult
>> to prove a negative, it seems that QGIS crashes don't happen (or at
>> least clearly happen less often). So I would like to transition the
>> project to PostGIS.
>>
>> I am asking for your recommendations or experiences with setting this
>> up in a way that will be fairly easy to show users who are technically
>> savvy but new to database management. Some details:
>>
>> 1. Small workgroup (5 or so).
>> 2. Spatial layers are big releases from city government (parcels,
>> streets, infrastructure) which are updated at most a couple of times a
>> year, often less frequently. Each spatial layer is updated on a
>> different schedule by different agencies.
>> 3. Data releases are in shapefile (blecch!).
>> 4. Users do meet in person with some regularity.
>>
>> As a suggestion, I am considering just having everyone set up
>> localhost installs of PostGIS. When there is a new data release, one
>> person could load and clean the data, then dump the table, copy the
>> dump to Dropbox, and other users could load the new table in their
>> localhost database.
>>
>> Obviously this solution is not scalable--more users or more frequent
>> updates would make it quite tedious--but it may work for this use
>> case. I am open to criticisms and suggestions.
>>
>> Thanks,
>> --Lee
>>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users

--
Lee Hachadoorian
Assistant Professor of Instruction, Geography & Urban Studies
Assistant Director, Professional Science Master's in GIS
Temple University
http://geospatial.commons.gc.cuny.edu
http://freecity.commons.gc.cuny.edu

_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users