Centralized vs Distributed GIS within a Municipality
K Majorhazi
The June 1994 issue of Geo Info Systems has a column entitled
"Is a GIS Department the Answer?" by Rebecca Somers.
This should provide you with some valuable information.
Over & out
------------------------------------------------------------
Karl Majorhazi ka...@storm.greta.cri.nz
GIS/Computer Graphics
N.Z. Oceanographic Institute, NIWA Ph: 64 4 386 1189
Wellington, New Zealand Fax: 64 4 386 2153
============================================================
> I would like to hear comments on the Pros and Cons of running a centralized
> GIS department versus a distributed system within a municipality. There does
> not seem to be an obvious approach and is some what dependent upon
> departmental politics.
>
> If anybody has some write up on this area on any comments or experience I
> would be happy to hear them.
>
> Wolfram Herdin
> City of Coquitlam
> whe...@gov.coquitlam.bc.ca
Herdin, Wolf
Georg Smehil
In my opinion a centralized management of spatial (cadastre) data do not
allow to develop applications in each involved engineering discipline
(involved utility). Having the spatial data of eg. sewer, not a map but the
hydrological simulations are the goal the sewer people have. Therefore the
gis has to serve as platform for dynamical data management and this simply
can not
be achieved if the whole municipal administration access and maintain the data
in such centralized system. Centralized gis are a priory monsters.
Distributed gis is much better but the shame - the available data bases
support the needed functionalty badly. Another obstacle is the common IT
knowledge of people who shoud cooperate. Further the realization is
expensive (do not forget the municipality is the client) and lot of
organizational changes have to be done. All this make the realization very
difficult.
I had a solution of a distributed data base system in 1990 but only one
organization - the surveying departement which distributes the base map in
the precision of +/- 3 cm over the area of about 100 km2 - use it. The
utilities were not able to UNDERSTAND whats about and are looking till today
for another solution. They are years away from production.
If you want more information I'll give you - in 1995.
George
************************************************************************
* Georg Smehil * E-Mail: sme...@eawag.ch *
* Swiss Federal Institute for * *
* Environmental Science And Technology * Phone: +41-1-823-5386 *
* Engineering * Fax: +41-1-823-5389 *
************************************************************************
Herdin, Wolf
within a Municipality. Standardizing with one GIS software package surely
make things much easier, on the other hand we are constantly being bombarder
by our users because they see deficiencies in the product we use (CARIS) and
are unaware of deficiencies in other products while viewing canned demos.
Having said this, we do not have data exchange problems internally or data
duplication because everybody accesses the same files for their own layers.
Moving on from data exchange problems ( not to minimize it ) to a
coordinated inter-departmental data entry approach. The main reason why I
posted the question was because we here at the City of Coquitlam have a
distributed approach whereby through data securities departments can edit
their own data, view and analyse any or all data if they so wish. This is
great, but because all data is referenced to base map data which is
controlled by Engineering. Data from all other departments must reflect the
change in their data. This causes problems because we currently do not have
an automated method of notifying the other departments such as Parks to
change a parks boundary if the legal has been changed in Engineering.
One answer to this would be to let Engineering take control of the Parks
layer so that parks boundaries referencing the legal can be changed at the
same time. This creates a domino effect to the point that we have a
centralized GIS agency (Engineering) to be in charge of the data and
specific non-Engineering needs may be cast aside.
Therefore I guess what I am really asking is, has anybody successfully
tackled the implementation of a distributed GIS that can keep the data
itself within one file but to allow editing, viewing and analysis functions
available to the privledge users and to specifically flag certain features
that are effected from the change of other features controlled by other
departments all while keep the inter-departmental political game out of the
GIS arena.
Wolfram Herdin
City of Coquitlam
----------
From: yuri
To: wherdin
Subject: Re: Centralized vs Distributed GIS within a Municipality
Date: Friday, December 23, 1994 3:25PM
Hi Wolfram!
I work as GIS specialist(GIS coordinator ???) for New York City
Department of Environmental Protection (DEP), more correctly, for
Division of Water quality and control (DWQC). Within DEP we have about
5 - 7 different divisions, maybe more. When I was hired 2 years ago, GIS
was planned only for DWQC but later on it turned out that other groups and
divisions had some sort of GIS already. We started ArcInfo and GRASS, while
other units are using Intergraph, MapInfo, GDS, AutoCAd, GISPLus, etc. Here
troubles start, because, if somebody on a higher level want maps or info
they
have troubles with formats of software as well as data formats. Also, if we
develop (and we do!) beautiful applications within ArcInfo for DWQC, then
other divisions want them but can't use, because of the d
ifference in a software. We had several meetings already discussing all
frustrations and came to one conclusion - we need centralized GIS group
which
can handle all training, data acquisition etc. issues.
So, you should be moving toward centralized GIS and standardize on GIS
software beforehand (you can definitely have not one, but two software which
has to be compatible!!!). This way you will avoid a lot of frustrations
which
we had experienced.
Bye, Yuri
Mark Stern
> <snip>
>Therefore I guess what I am really asking is, has anybody successfully
>tackled the implementation of a distributed GIS that can keep the data
>itself within one file but to allow editing, viewing and analysis functions
>available to the privledge users and to specifically flag certain features
>that are effected from the change of other features controlled by other
>departments all while keep the inter-departmental political game out of the
>GIS arena.
I believe this sort of functionality is avaiable in SmallWorld, because of
it's clitn-server structure. Perhaps you could contact the SmallWorld
people and they may be able point you to some reference sites.
Mark Stern
M.W....@massey.ac.nz
JaysonBr
The size of the City.
Existing Computer Systems within the municipality.
Financial Stipulations.
In most cases, it is possible for a municipal GIS in a city of 75,000 or
less to sufficiently on one PC or local area network. A person can be
assigned to operate the system and fill requests for people.
If the City is larger or has more money, a centralized GIS can be put in
place and in most cases is run by the City MIS departments. Smaller
systems are usually run within a department like planning, Engineering or
utility department.
In my personal experiences, a GIS that involves all city departments is
best. This does not mean that the hardware running the GIS has to be
centralized, it can be located within one department and access can be
given to other departments via downloads. This is the inexpensive way
out.
Anyway, have have some papers I have written regarding municipal GIS
implementations. Give me your name and address and I'll send them to you.
Until last year, I was the GIS manager for the City of Concord, NH. We
developed a system totally in-house and operated it through the MIS
department. It really worked out well. The system was PC based.
Let Me know
Jayson Brennen
Georg Smehil
.
.
>Therefore I guess what I am really asking is, has anybody successfully
>tackled the implementation of a distributed GIS that can keep the data
>itself within one file but to allow editing, viewing and analysis functions
>available to the privledge users and to specifically flag certain features
>that are effected from the change of other features controlled by other
>departments all while keep the inter-departmental political game out of the
>GIS arena.
.
.
Yeah there is an implementation of distributed GIS in city of Zurich =
350'000 inhabitants and 100 km2.
The principles governing the solution are:
1. Each department is responsible for its data (capture, maintenance,
backup etc.) and its own system.
2. Each department develop around the common data base (GIS?) its own
application software for modeling its own discipline.
For example the hydrology department developes the
application software implementing hydrological models (there are
a couple of dozens of them) etc.
3. Each department can COPY (not fetch!) the NEEDED part of the city and
the needed thema from all other departments to its own system.
Than it can do everthing with this data except to copy
it back to the original system. Sort of "shoot and forget".
Especially it can edit its special map or design its project for
its own purposes. Copying only the needed part of the data sets
reduces significantly the problem of data quantity.
4. The data will be copied "as is". If there is something wrong in
the data, the guys have to TALK together and fix it on the error side.
5. The spatial (or geometric - no geographic!) data are in a high
precision. They are derived from the surveying department's base data set.
This base data set represents the 2D-virtual reality in the scale 1:1.
The error mean over the whole area is +/-3 cm, so the derived data
sets of the other departments (utilities) reach the precision of +/-10 cm.
Deriving all spatial data sets from the high precision geodetic base data
set harmonizes the overall picture and makes no further problems
with digging outside.
6. The data transfer rate is about 12 hectares of the base data set
per minute. No limitations of number of users (not above 100).
7. After the copied data sets were used, they can be deleted. The other
departmens made probably changes in their data sets, so the next copy
will get the fresh updated data subsets.
8. The idea behind this concept is to avoid the production of paper maps.
That's it. There is a prototype of this solution implemented, but only
the surveying department use it as its information management system
(Client/Server system for project and update purposes). The other
departments prefer to get the base data off-line because they
simply didn't UNDERSTAND what's about. Nevertheless the investment in
their data sets will not get lost, because the derived data sets will
have the necessary precision.
I dont't see any possibility to realize a centralized solution because
all involved disciplines represented by corresponding departments have to
realize completely different information systems which each of them will
grow huge. So the centralized information system would never allow further
developments. There are limits in the people's communication ability.
On the other hand the common denominator of all information systems
is only the compiled cadastre. The allover coordination
between the participants can be reached sole by the precision
of the base data set and by the speed of getting the relevant data subsets.
Nothing about object orientation, referentiel integrity, spatial analysis
or similar. All this is nice to have but its not crucial for what happens
in the municipalities.
I hope this can give some ideas about the question centralized/decentralized
GIS.
George