Comments on: GIS Data is an Illicit Drug http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/ Exploring the Realms of GIS and Other Stuff Mon, 08 Mar 2010 13:19:07 +0000 http://wordpress.org/?v=2.9 hourly 1 By: David Raybuck http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/comment-page-1/#comment-49709 David Raybuck Mon, 12 Jan 2009 18:47:47 +0000 http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/#comment-49709 I'm coming in way late here, but I'm doing a grad school project on enterprise GIS data and knowledge management and would love to hear about any successful solutions these problems. I’m coming in way late here, but I’m doing a grad school project on enterprise GIS data and knowledge management and would love to hear about any successful solutions these problems.

]]> By: Matt Perry http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/comment-page-1/#comment-17 Matt Perry Thu, 30 Mar 2006 06:58:59 +0000 http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/#comment-17 You hit the nail on the head, Gary. Revisions are necessary since all data needs to be massaged for analysis or cartography. Currently the most practical way to do this is to make a new dataset. You spawn new datasets to make minor changes, to join with attribute tables, to reproject, to test processing steps on smaller clipped regions, to move to another platform or another software package, etc. So you've got a dozen datasets on three machines all essentially representing the same thing with cryptic names like eu_bord_clip, eu_bord2, etc. Then you realize you made some minor mistake in the original parent dataset. Ahhhh.... So thinking pie-in-the-sky here, what would be the ideal solution? I was dreaming of a CVS /SVN central repository-like system where each user could check out their local copy, make changes to the dataset in their software of choice. Those changes can be checked back in, split into branches, rolled back to previous versions and all the metadata is managed internally. Using a data abstraction layer, the data could be checked in/out in any format so users could download and work with whichever format they needed locally. I can't imagine the logistics of building such a system but it's always nice to dream. You hit the nail on the head, Gary. Revisions are necessary since all data needs to be massaged for analysis or cartography. Currently the most practical way to do this is to make a new dataset. You spawn new datasets to make minor changes, to join with attribute tables, to reproject, to test processing steps on smaller clipped regions, to move to another platform or another software package, etc. So you’ve got a dozen datasets on three machines all essentially representing the same thing with cryptic names like eu_bord_clip, eu_bord2, etc. Then you realize you made some minor mistake in the original parent dataset. Ahhhh….

So thinking pie-in-the-sky here, what would be the ideal solution? I was dreaming of a CVS /SVN central repository-like system where each user could check out their local copy, make changes to the dataset in their software of choice. Those changes can be checked back in, split into branches, rolled back to previous versions and all the metadata is managed internally. Using a data abstraction layer, the data could be checked in/out in any format so users could download and work with whichever format they needed locally. I can’t imagine the logistics of building such a system but it’s always nice to dream.

]]> By: Jason Birch http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/comment-page-1/#comment-16 Jason Birch Thu, 30 Mar 2006 05:39:14 +0000 http://spatialgalaxy.net/2006/03/29/gis-data-is-an-illicit-drug/#comment-16 Spot on analysis. I'm lucky enough to see a push for consolidation in my current job, but here are some more scenarios that lead to data proliferation: - The original enterprise data model failed to recognise an existing need, or is inflexible in adjusting to new requirements. - Client software requires update access to the database for making styling changes (is this GIS or Illustrator folks?) - The organisation's GIS users are balkanized both by the organisation and by technology. Data models and databases that are readble by one department need scheduled translations for usage by other departments. - The update cycle is broken. The maintaining department is unresponsive to error notifications and change requests. - The complexity of client-side setup for new data models is high, creating a barrier to data model changes. Honestly, I'd rather say that it's a managment problem so that my manager has to deal with it :) Jason Spot on analysis.

I’m lucky enough to see a push for consolidation in my current job, but here are some more scenarios that lead to data proliferation:

- The original enterprise data model failed to recognise an existing need, or is inflexible in adjusting to new requirements.

- Client software requires update access to the database for making styling changes (is this GIS or Illustrator folks?)

- The organisation’s GIS users are balkanized both by the organisation and by technology. Data models and databases that are readble by one department need scheduled translations for usage by other departments.

- The update cycle is broken. The maintaining department is unresponsive to error notifications and change requests.

- The complexity of client-side setup for new data models is high, creating a barrier to data model changes.

Honestly, I’d rather say that it’s a managment problem so that my manager has to deal with it :)

Jason

]]>