|
giswr
> events
> feb 2000 giswr conference
> thursday morning discussion
Thursday Morning Discussion
Notes prepared by Kwabena Asante, CRWR
1) Should points along a network be treated as separate
classes from those off the line? How do you treat BMPs and
other features which may or may not be on the network?
2) ÑSuggestion that we treat whereness, whatness and organization
separately and determine which of these three attributes
should form the basis for determining the definition of
a class. The OGC (Open GIS Consortium) has examined the
issue extensively and a review of their findings would provide
insight into the pitfalls of using one or other of these
definitions in the creation of classes.
3) With regard to control points, how do you handle changes
in the location, direction or quantity of flow past a control
point? Should time series be treated as a separate object
and if so how is it linked to the control point?
4) How do we handle situations in which flow direction
on a reach can change with the quantity of flow or season?
One suggestion was to provide two reaches between nodes,
one in each direction, and allow flow to go down each reach
as a function of the condition of flow. A second suggestion
was to regulate the direction of flow in a single reach
through the use of relationships. An enable disable switch
was proposed as another way of altering flow direction in
a flow element. A third suggestion was to leave out flow
direction in the definition of the core data model structure
and let network analysis be used to regulate flow direction.
In other words assign a single flow direction and let negative
or positive quantities of flow past a control point indicate
the direction of flow.
5) With regard to the definition of hydrolines, the question
of other features such as streets acting as conduits of
water was raised. The question of how these should be represented
in the data model was raised.
6) The observation was made that the definition of a river
profile consisting of a channel centerline with cross sections
at selected points along it should be recognized as a new
data type in the same way we treat coverage, DEMs and TINs.
This would allow river profiles to be requested from contractors
and other data developers as standard products.
7) Questions were also raised about the differences between
profile lines and hydrolines. Should a profile line be a
subclass of hydroline or should it be a separate class?
Is there a key field linking profile lines and hydrolines?
How are changes in geometry and seasonal changes in the
definition/outline of features to be handled? A suggestion
was made to define multiple polygons/lines for different
seasons.
8) What terms should be used in the data model? Should
traditional terms like Thalweg be used or should they be
substituted for generic terms like centerline?
9) How are measures on a polygon (such as docks on a lake)
to be handled? An example of polygon boundary measures in
whichÑ quantities are defined in a counter clockwise direction
from a fixed start point such as the discharge location
of a lake was given.
10) A question was raised on how braided channels which
result in multiple cross sections on the flood plain could
be handled.
11) A discussion was initiated on how hierarchical systems
such as HUCs would fit into the definition of the data model
particularly in view of the additional levels being developed
by local entities. A suggestion was made that for a given
level of the hierarchy (say 4 digit HUCs), both the riverline
and the drainage area associated with it should carry a
hydroline-id of the same level. On the question of how a
hierarchy system would operate for users whose definition
of drainage area boundaries are not coincident, it was suggested
that the notification system could be used to pinpoint such
differences for further review and resolution.
12) Questions were raised on how such a system would operate
for those users who choose not to use the one to one relationship
between riverlines and drainage areas or those who do not
delineate drainage areas from river junctions would fit
into such a system. A suggestion was made that control points
could be used to identify the starting points of delineations
in such systems. The data model would thus be sufficient
for such cases.
13) The question of how areal aggregation could be done
in a vector environment was also discussed. An observationÑ
was made that drainage areas delineated from pourpoints
would ensure a one to one relationship between drainage
areas and river reaches allowing area to be aggregated on
both elements at the pourpoints. It was suggested that the
approach would be limiting since several agencies such as
the HEC specifically avoid performing delineations from
pourpoints. They opt to delineate drainage areas from gauge
locations which generally avoid stream junctions because
of numerical stability and other practical considerations.
It was suggested that delineation points be defined as addition
control features on which area could be aggregated instead.
14) After a short break, discussion resumed on the definition
of drainage areas. It was observed that drainage areas may
or may not have pourpoints. They may also have more than
one pourpoint. It was observed that within the US, at least
two classes of RCS (?) and USGS.
15) A question was raised on how measurements at different
depths would be handled.
16) It was suggested that an additional field be attached
to the core models to allow for remarks and for attributing
the quality of a measure.
17) The question of aggregation versus composition was
briefly discussed.
18) The role of the raster data in the object environment
was raised but discussion was deferred to the session on
raster object modeling.
19) A concern was raised about the fact that most discussion
in the consortium focused on object oriented modeling as
a new way to treat data with little reference to how the
data in the model could be used. The suggestion was made
that the first step in the process was to get the data model
straight before turning the focus on its uses. However,
concern was expressed about the need to keep track of ways
of getting the data out of the model during the data model
definition process.
|
