![Who am I ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Foss4g evolution-gis-data
Similaire à Foss4g evolution-gis-data (20)
Foss4g evolution-gis-data
- 1. Evolution of GIS data booth # 12 By Joachim Van der Auwera
- 9. Solutions
- 10. Possible solutions Workflow solution Long lasting transactions Editing layers Timestamp based data versioning Revision based data versioning
- 15. Use cases & solutions, overview Workflow solution n/a n/a ✓ ✓ Long lasting transactions ✗ ✓ ✗ ✗ Editing layers ✗ ✓ ✓ ✓ Timestamp based data versioning ✓ ✓ ✓ ✗ Revision based data versioning ✓ ✓ ✓ ✓
- 18. Spatial database solutions database native data versioning ? extensions or plug-ins ? PostGis no * (timetravel, geoserver) Oracle Spatial yes Flashback DB2 yes (DB2 10) MySQL no * MS SQL yes Change Data Capture
Notes de l'éditeur
- Welcome to this talk about the evolution of GIS data. I will first introduce myself. I am jvda, a technical guy (some would say a “nerd”). My career in user oriented programming began more than 20 years ago. Half of which was as an open source proponent, using Java. Focus on enterprise software, and I always seem to end up worrying about code quality and maintainability, build environment and tooling, strong architecture, consistence, documentation, ease of programming. Joined Geosparc and the GIS world in August 2009 Part of the three headed dragon which leads Geomajas development.
- dictionary.com gives 9 meanings for evolution, a couple of which are displayed on the slide.. For the scope of this talk, I will focus on the fact that data in GIS systems in usually not static. It has to change because of changes in the real world. This has implications both on the data and data storage and the management of the data. Let us consider a couple of use-cases.
- Probably the most straightforward case is to be able to display the data which was current a a specific moment in time, whether this is now, last week, or in the case shows, more than 200 years ago.
- Another case is making changes which take a long time. Maybe they are complex, or there is a coffee break, or you have to rush home to get the kids from school and continue the day after. You don't want people to see the features halfway of your editing, you only want the end result to be public.
- A more complex variant of the previous case is that the changes may also need to be verified and approved by someone else. You see a work-flow of two people, one doing the editing (bottom), and one doing the checking.
- There are two areas, data management and data storage. For the management, there are workflow or business process modelling and execution solutions. These are typically for the interaction of different parties and/or servers. Secondly thereare the options for data storage. ...
- Postgresql TimeTravel is deprecated Geoserver, gt2-postgis-versioned modules, opengeo DB2 : since june 2010, on time SELECT AVG(SALARY) FROM EMP SYSTEM VERSIONS AS OF '2009-06-13-00:00:00:000000000000' WHERE deptno = 'SW1 MySQL: DDEngine.org http://www.mysqlconf.com/mysql2009/public/schedule/detail/6205
- Let's step back a little. The first relational database, ADABAS was released in 1970. Youw wrist watch is probably more powerful than the mainframes of that time. Especially storage space, both in memory and on disk was “scarce”. There was no space to keep historic data and just having the current state was already revolutionary. Of couse the data did change, so transactions were introduced to assure data consistency. These days storage is “cheap”, so should we still write software applying restrictions from 4 decades ago?
- Let's step back a little. The first relational database, ADABAS was released in 1970. Youw wrist watch is probably more powerful than the mainframes of that time. Especially storage space, both in memory and on disk was “scarce”. There was no space to keep historic data and just having the current state was already revolutionary. Of couse the data did change, so transactions were introduced to assure data consistency. These days storage is “cheap”, so should we still write software applying restrictions from 4 decades ago?