[OSGeo-Discuss] Internship Opportunities @ Open Source Geospatial Lab
First phase of Internship opportunities are now advertised for various Open Source projects at the Open Source Geospatial Lab (OSGL) at the Centre for Geospatial Science, University of Nottingham. Details at http://www.nottingham.ac.uk/cgs/news/internships.aspx Application closing date: 15 Oct 2010. Best wishes, Suchith Dr Suchith Anand Centre for Geospatial Science The Nottingham Geospatial Building University of Nottingham NG7 2 TU Tel: (0)115 82 32750 http://www.nottingham.ac.uk/~lgzwww/contacts/staffPages/SuchithAnand/Suc hith%20Anand.htm http://www.nottingham.ac.uk/~lgzwww/contacts/staffPages/SuchithAnand/Su chith%20Anand.htm http://www.opensourcegis.org.uk/ http://www.opensourcegis.org.uk/ http://ica-opensource.scg.ulaval.ca/ http://ica-opensource.scg.ulaval.ca/ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] Re: git like for geodata management
Hi Noli, thanks for the link. That is definitely a step in the right direction, but it is hardly comparable to git ArcSDE versioning at that. The article and sample code you describe above generates hashes for all rows and tables in the db and compares them to the target db. So 1 million rows in a db, regardless if the two dbs are identical, would cause 1 million hashes to go over the wire. Every single time you ask to sync you pay the price. Git and ArcSDE keep track of changesets, and when it is time to synchronize, they exchange that changeset and apply it. One insert? That is all that needs to be sent. Another issue is that there is nothing about conflict resolution there (what happens when you delete one row in one db and modify it in another one?). There is also the problem of allowing multiple versions of the data in the same db (Like having multiple heads). Regardless, thank you for the link, - Ragi Date: Thu, 23 Sep 2010 13:22:17 +1000 From: Noli Sicad nsi...@gmail.com Subject: Re: [OSGeo-Discuss] Re: git like for geodata management To: OSGeo Discussions discuss@lists.osgeo.org Message-ID: aanlkti=3anc4baand4hk9uuzfsasxn-8ybpnkyong...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 PostgreSQL Synchronization Tool --- psync [1] The article introduces a method of synchronizing two PostgreSQL databases. Although, this seems to be an easy task, no product (slony, londiste, ...) really satisfied the needs within the maps.bremen.de project. Either they have special prerequsits that didn't apply for our problem or they didn't support synchronizing of large objects. Large objects are used to store tiles of a street/aerial map within PostgreSQL. My GIS-server queries the database and gets the tiles out. By using this construction we are getting a flexible infrastructure for updating and maintaining different versions of the maps. Everything was working fine until the service needs to be spread over three servers. How can we easily synchronize the databases? I really found no really working solution that is clean and easy to use. [1]http://www.codeproject.com/KB/database/psync.aspx Noli On 9/23/10, Ragi Burhum r...@burhum.com wrote: Are you looking for an alternative to (1)ESRI's versioning, (2)ESRI's disconnected editing, or a mix of both (3)git like? the scenario that you described first was more like (2), but this one fits (1). I would love to see something like (3), but truth of the matter, AFAIK, there is nothing like that implemented for geo (yet). On Sep 22, 2010, at 9:00 AM, discuss-requ...@lists.osgeo.org wrote: On Wed, 2010-09-22 at 12:10 +0800, maning sambale wrote: Any real world cases for this? Imagine the following scenario: * 50 ~ 70 digitizers * 5 QA * 1 Manager Each QA has 10 digitizers assigned. After all the data is validated, the manager merges it and generates the geodb. All users work against the same DB, most of them linked. This causes disconnections, duplicated data, and lots of random errors. Also, they can't be forced to work on different DB's because they are all working on the same project, at the same time. This is the real scenario of GISWorking (http://www.gisworking.com/), a company we are working with. It would be perfect to have smaller groups (ideally 1 person), working against separated databases, but that can be synchronized with the rest of the data when needed. Then each QA merges data from the people he supervises. After it's validated the manager merges the complete dataset, and generates the final product. I don't know if this it's the exact same case, but we are working on it with a similar approach. ___ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Re: git like for geodata management [SEC=UNCLASSIFIED]
Ragi, I agree. I think that we have a way to go yet to have something comparable to the ArcSDE / ArcGIS Multi-versioning and version conflict detection functionality. The advantage that the ArcSDE solution has is that edits are made directly within the database. This works well within an Enterprise environment as described by Fabio earlier in this thread. I may be wrong, but I think that git works on files, but I haven't used it myself. Can git detect changes to the spatial representation of a feature within a binary file? Also, speaking as someone who implemented an ArcSDE/ArcGIS Multi-versioned edit scenario several years ago, the ESRI solution is far from perfect. It imposes very strict environment management on the system managers, e.g.: * All versions of the software used (client and server) must be at precisely the same version, service pack and patch; * The environment can only use software that implements the ArcObjects environment (from experience, this rules out the use of the ArcSDE Java and C API's); * Editors must be well trained and knowledgeable in using both ArcGIS and Multi-versioned processes; * The Organisation needs to think through their maintenance processes to get best advantage of the functionality; and * It doesn't remove the need for data maintenance people to talk to each other about work that is going on, as the software cannot resolve all conflicts. For example, if two editors make changes to the spatial representation of a feature, which one is correct? The software will detect the conflict, but the editors (or their managers) will need to resolve the issue of which version of the feature's spatial representation is correct. Bruce On 24/09/10 4:05 AM, Ragi Burhum r...@burhum.com wrote: Hi Noli, thanks for the link. That is definitely a step in the right direction, but it is hardly comparable to git ArcSDE versioning at that. The article and sample code you describe above generates hashes for all rows and tables in the db and compares them to the target db. So 1 million rows in a db, regardless if the two dbs are identical, would cause 1 million hashes to go over the wire. Every single time you ask to sync you pay the price. Git and ArcSDE keep track of changesets, and when it is time to synchronize, they exchange that changeset and apply it. One insert? That is all that needs to be sent. Another issue is that there is nothing about conflict resolution there (what happens when you delete one row in one db and modify it in another one?). There is also the problem of allowing multiple versions of the data in the same db (Like having multiple heads). Regardless, thank you for the link, - Ragi Date: Thu, 23 Sep 2010 13:22:17 +1000 From: Noli Sicad nsi...@gmail.com Subject: Re: [OSGeo-Discuss] Re: git like for geodata management To: OSGeo Discussions discuss@lists.osgeo.org Message-ID: aanlkti=3anc4baand4hk9uuzfsasxn-8ybpnkyong...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 PostgreSQL Synchronization Tool --- psync [1] The article introduces a method of synchronizing two PostgreSQL databases. Although, this seems to be an easy task, no product (slony, londiste, ...) really satisfied the needs within the maps.bremen.de http://maps.bremen.de http://maps.bremen.de project. Either they have special prerequsits that didn't apply for our problem or they didn't support synchronizing of large objects. Large objects are used to store tiles of a street/aerial map within PostgreSQL. My GIS-server queries the database and gets the tiles out. By using this construction we are getting a flexible infrastructure for updating and maintaining different versions of the maps. Everything was working fine until the service needs to be spread over three servers. How can we easily synchronize the databases? I really found no really working solution that is clean and easy to use. [1]http://www.codeproject.com/KB/database/psync.aspx http://www.codeproject.com/KB/database/psync.aspx Noli On 9/23/10, Ragi Burhum r...@burhum.com wrote: Are you looking for an alternative to (1)ESRI's versioning, (2)ESRI's disconnected editing, or a mix of both (3)git like? the scenario that you described first was more like (2), but this one fits (1). I would love to see something like (3), but truth of the matter, AFAIK, there is nothing like that implemented for geo (yet). On Sep 22, 2010, at 9:00 AM, discuss-requ...@lists.osgeo.org wrote: On Wed, 2010-09-22 at 12:10 +0800, maning sambale wrote: Any real world cases for this? Imagine the following scenario: * 50 ~ 70 digitizers * 5 QA * 1 Manager Each QA has 10 digitizers assigned. After all the data is validated, the manager merges it and generates the geodb. All users work against the same DB, most of them linked. This causes disconnections, duplicated data, and lots of random errors. Also, they can't be forced to work on different DB's because they are all working on the
[OSGeo-Discuss] Presentation: How to sell Open Source to Government
I had a number of requests to share my presentation I recently gave on How to sell Open Source to Government, which I recently presented at the Open Source Software / Asia Pacific conference. A video of the presentation is now online at: http://cameronshorter.blogspot.com/2010/09/how-to-sell-open-source-to-government.html -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
