proposed changes of HY_Network representation

[IrinaDornblut]

1) network representation of catchment renamed as 'networkCartography' to express verbally what is really meant: physical, topographic, or other thematic maps or geoschematic views, showing the hydrographic network of water bodies, the network of channels, or a hydrometric network of stations that in its entirety, separately or as set of layers, represents a catchment without describing the displayed network parts in detail

2) generalization of hydrographic, channel and hydrometric network replaced in favour of an association to a cartographic visualisation of the network (networkCartography), to avoid confusion with the logic network of water bodies, channels or stations

3) network definitions not changed

[dblodgett-usgs]

I think this is a good change. Go ahead and incorporate into the model on github and we'll mention it on the next call?

Note that visualization has a typo on the association between hydrographicnetworkand networkcartography.

[lieberjosh]

I’m a bit confused, though. If networkcartography is a visualization of a topological network, why is it a feature type?

It’s another question for another time (perhaps) whether elements of a hydrographicnetwork should also be feature types, since topological elements are constraints on relations between features, not features themselves.

[dblodgett-usgs]

Good question! This is out of my depth to have an opinion on.

[lieberjosh]

I think I understand the purpose, to model a pseudo-spatial or non-spatial representation of a network such as an idealized subway map (aka geoschematic). It is sometimes done by creating imaginary feature geometries that when mapped a GIS, generate the representation, although now ArcGIS has a (proprietary) function and format for generating (geo)schematic diagrams. I feel it would be misleading to call such elements features, though.

[sgrellet]

´It’s another question for another time (perhaps) whether elements of a hydrographicnetwork should also be feature types, since topological elements are constraints on relations between features, not features themselves.´

I guess you mean that, water being a continuum, there is no real way to consider/delineate one waterbody within it. Thus waterbody is not an abstraction of a real world object. Thus not a FeatureType. good point. on the other hand in GeoSciML4 ´mappedFeature ´ is a FeatureType and in GWML2 flow elements are also FeatureType. we may need to FeatureType it anyway just to provide it with an identity. This might also be an answer to your question regarding ´networkcartography ´

Sylvain

P Pensez à l'environnement avant d'imprimer ce message Think Environment before printing

Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné(s) comme tel(s). En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de contamination à sa réception.

The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. This email was scanned for viruses, vandals and malicious content.

[IrinaDornblut]

1) From my understanding , a cartographic/geoschematic representation does not define the topological relationships between hydro features, but displays the topological properties defined (and expressed by typical associations) between the represented features, i.e. between catchments; each cartographic/geoschematic representation of a catchment portrays the catchment by displaying/drawing those (connected) features as which the represented catchment appears in the perspective of the undertaken study, e.g. as hydrographic network of water bodies, channel network, network of huc regions, network of stations, etc.

2) The different …Networks itself are not understood as special data products representing a catchment (that’s why the initial generalisation is removed), but as a phenomenon the catchment 'appears' depending on the perspective of the study. To separate the cartographic representation (data) of a catchment from such an application-specific view in a layer/map, each …Network is associated with a possible cartographic ‘visualisation’ (association replacing the former generalisation). Having a name in common usage and typical properties, each network as well as each of its parts are defined as features on its own (‘waterBody’ type = abstract notion of the water body, or channel’ type, or ‘hydrometricFeature’ type, or ‘…network’ for an aggregate of these).

3) I agree to define the ‘networkCartography’ class as ‘dataType’, and also the other special types of catchment representation. –

4) I will prepare a new html view for the next call

[dblodgett-usgs]

@rob-metalinkage - Assigned to you to review and comment. If you'd like to work up a new summary issue that encapsulates several issues, I would be supportive of that.

[dblodgett-usgs]

I think we've done this issue justice. We should rinse and repeat through review and discussion.