mappingMatrix

[IrinaDornblut]

my understanding of the semantic mapping is to show conceptual equivalence/similarity of contextual (implemented) concepts, e.g. INSPIRE context) and the base concept they realize, and not theone-to-one mapping for each posssible property, based on the detailed annotation given to each uml class and class property. - this could be shown using a simple mapping matrix indicating (a degree of ) equivalence.

a very simple matrix at very early stage how it may lokk like is posted under "reference docs". if you agree on such a simple approach, I will continue working on this Sylvain.

[sgrellet]

The issue I have with that view is that it may be too simplistic. When we map 2 different conceptual views of the same domain we don't always end up in a 100% equivalent mapping We often have to explain the differences (not always tiny) that exist when we do compare definitions, attributes, ...

We even discussed with Mickaël whether it may be useful to add a column in the mapping table we circulated to quantify the mapping : 100%, 50% equivalent.

[dblodgett-usgs]

I agree this is likely too simplistic. I could see adding a qualitative equivalence field. Options would be like exact, partial, and minimal. A comments field would be used to describe the choice.

[sgrellet]

One option would be to work on the more detailed view. And then generate a more simplistic view from it more for communication purposes

[dblodgett-usgs]

:+1:

[IrinaDornblut]

yes, fine. - I have in mind to add a degree of mapping, mybe percentage. - and a reference to the clause in the standard doc for "further reading".

[mbeaufils]

Matrix representation is interesting. I'm just thinking on how adding granularity to it.

Maybe in defining some criteria for the mapping (ex : Semantic, geometric representation).

• adding some relationship between terms (ex : this term IS INCLUDED in this term, or this term INTERSECTS this term) like for spatial analysis.

[sgrellet]

I see this ending using terms broader, narrower … ☺

[mbeaufils]

that's the idea. I think we could find a list of those "semantic relationship operators" in ontology works.

[aolite]

Agree with Irina!!! :)

It is interesting to generate a mapping matrix between HY_FEATURES and INSPIRE Directive. This mapping could be included inside the HY_FEATURES ontology as annotations in order to:  Materialise the mapping on INSPIRE data models when the models will be available as a semantic resources. As a rules to encapsulate INSPRE data models (XML -instances of INSPIRE-) into a HY_FEATURES model (RDF/XML, JSON-LD, etc) using XML2RDF or XSLT transformation for the conversion (at deployment stage). 

In order to represent the geometries, I propose to use GEO-SPARQL (compatible with geo-reasoning) semantic model.   This model can be used as an extension of HY_FEATURES (combination between semantic models specifically by each demo-site). 

Anyway, Irina count with me to construct the mapping matrix with INSPIRE ;)

[rob-metalinkage]

https://wiki.csiro.au/display/SIRF/ModelMappingHi all - sorry have been a little quiet - but a few perspectives here

I think a table summarising where mappings exist between elements is a useful thing - but its not the same as a mapping that can be explicit, testable or executable.

Actual mappings are definitely not 1:1 - one of the most common cases is where a complex concept is broken down into a set of related scalar attributes - eg "downstreamCatchment" and "downstreamCatchmentType" and "downstreamCatchmentArea" to map several properties of the downstream catchment object as simple scalar attributes of the object (eg a polygon catchment area representation).

The key mapping behaviour we care about is identity of classes however - the mapping needs to express something like "the identity of an instance of this type (A) can be mapped by some process to the identity of a single instance of type B"

If classes have attributes that do not map - thats fine - classes may extend concepts - e.g. add the number of breeding marmots per catchment. attributes can be mapped to any attributes of any related classes - but the mapping may need to specify constraints on these relations - on either end of the mapping.

Consider a data model which has multiple "catchmentid, relatedCatchment, relationtype" - hoding relationtypes "downstream" and "upstream" - obviously only some of these match to a "upstreamCatchmnet" relation.

An executable mapping can definitely be expressed in an ontology - (which is highly flexible) - and possibly other formalisms. It can also be expressed by "making up" an equivalent set of information in UML - we can just add value in tags to elements - UML can be fully isomorphic with any ontology if we define the expression conventions to use.

So - lets kick off with a table - but to fully test the mapping lets see if we can build an ontology. Do have some tools to do this in UML (https://wiki.csiro.au/display/SIRF/ModelMapping) that we know can handle such mappings from GML or ArcGIS datastructures - but we also expect a formal OWL based mapping language to emerge at some time - but these are still emerging: such as the activity BRGM referenced at Orleans.

Cheers Rob

[lieberjosh]

One of the primary decisions will be whether the relationships are classification one, in which case SKOS is the place to start, or sub/superclass relationships, in which case common superclasses are needed, or something unique to the geo / hydro domain (e.g. shares location, shares water). Only the second option allows for a common reasoning approach between hydro systems.

[rob-metalinkage]

Actually - i think it is polymorphism relations that matter - knowing that instances of two classes may be talking about the same real world object - its like having an implied shared superclass - without having to model this separately.

guidance on the reasoning implications of each possible approach would be helpful - my feeling is that SKOS mapping is too inexpressive and OWL or RDF subclassing would probably give rise to unwanted inferences?

though maybe it possible to use subclassing - as long as the subclassing is defined in a separate graph that is only imported for certain types of reasoning? we wouldnt want to inject this into every data product model .

rob

[aolite]

I think that we need to try to construct and ontology that performs RDF reasoning (e.g hierarchical reasoning) as much as possible.

The possibility to include SKOS relationships inside the semantic model could be benefitial if we want to merge two semantic models into big one. However (as Rob said), we need to take into considerations the reasoning costs (as well as increment of the semantic complexity) of merge two specific semantic modes (HY_FEATURES and othes) and an upper ontology that links them (e.g SKOS).

In my opinition, after constructing the mapping matrix table we can clearly evaluate if extend HY_FEATURES, map HY_FEATURES using SKOS or even include external elements to give HY_FEATURES the possibility to be extended with other semantic models (e.g GeoSPARQL to mention one).

As an example, I extended the water-ontology generated inside the WatERP project with the Geo-SPARQL by including all geo-referenced classes of the water-ontology inside the element geo:Features (class of GeoSPARL to represenet gegraphic entities). Then, to perform georeasoning over the water ontology, we merge both models (importing them) that automatically links the both nexus points (like a puzzle) (in this case by geo:Features).

With this example I have tried to describe that we can include define classes that serves to link HY-FEATURES with external and different domains semantic models. In case of linking similar domain semantic models (e.g HY_FEATURES with other hydro-domain ontology), I am partidary of making HY_FEATURES more general as possible to include those concepts by extending the HY_FEATURES for example, what do you think?

[sgrellet]

All,

I think we are discussing things here

• A°/ Comparing HY_Feature with another model (national, community) so that HY_Feature content is useful for domain people (i.e : we don’t miss important information) + the formalism to document the comparison (mapping table).

This requires in depth domain analysis of what each feature definition, attribute, association mean in both models.

This takes time and gives ‘domain’ headaches

• B°/ Go further with this mapping exercise so make it explicit, testable or executable.

This triggers IT discussion about the technique to be used.

That’s a subject we discussed a bit during the Orléans hydroDWG workshop (based on HY_Feature and GWML2 experience) and I’d love to push it forward.

This also takes time and gives ‘IT’ headaches (luckily both types of headaches go away with some rest J)

Initial aim of the mapping table we started discussing yesterday is definitely of type A. Of course, from an IT perspective we want to go beyond what may appear a ‘simple’ exercise. In order to move forward quite fast I think we may not want to carry out both exercises altogether.

As Rob concluded, can we validate we do the following ?

• 1°/ finalise the domain content approach (A°/).

I think a ‘spreadsheet’ approach is sufficient

This will help us stabilise, validate and ultimately communicate on what HY_Feature is useful for.

• 2°/ then port it to a more IT meaningful approach (B°/)

BTW : who will be at Washington TC ?

I’ll be there and happy to start looking at how we could port part of the mapping using the framework proposed by Rob.

And maybe discuss other way around : “we also expect a formal OWL based mapping language to emerge at some time” -> in GWML2 UseCase 5 took a quick look at EDOAL

Sylvain

[mbeaufils]

Hi everyone,

As for A°/, I suggest keeping the matrix approach introduced by Irina, but with more “qualitative information about the mapping” as we discussed before. I see two criteria on which we can focus on : semantic, geometric.

For semantic, three possible values to describe the mapping :

•    Synonymy : Both terms address the very same concept,

•    Hyperonymy : Concept X can be seen as a specific instance of the more general concept Y,

•    Partonymy (or Meronymy) : Concept X deals with a part of Concept 2.

For geometric, also three possible values :

•    Same representation : Both concepts are represented the same way,

•    Derivative : Representations are different but one may be obtained from the other (eg. area vs. boundary of this area),

•    Not compatible : Representations are different and geometries cannot be linked together.

I think we can include both information in each cell of the mapping matrix (eg. using colors for geometric mapping and maybe a letter for semantics).

Mickael

[IrinaDornblut]

Hi,

YES, what we need NOW is, to express the compatibility of concepts, and not an “in depth domain analysis of what each feature definition, attribute, association mean in both models” (this is a mapping implementation issue).

However, to have a stable basis for the work on the “ontology/owl” version of HYF (intended part 2) and to develop a mapping formalism later on, the compatibility of concepts should be expressed in a formalized way.

So, let’s continue working on the “spreadsheet” (which is a two-dimensional matrix) expressing the compatibility of concepts (e.g. “INSP meets HYF”) using an approach consistent in itself.

I am happy to work with.

Irina

[IrinaDornblut]

short summary - Sylvain, Mikhail and I will continue work on the “spreadsheet” (two-dimensional matrix) expressing the compatibility of concepts (e.g. “INSP meets HYF”) using an approach consistent in itself.

this may form the basis for further work on the “ontology/owl” version of HYF (intended part 2) and to develop a mapping formalism later on, provided that the compatibility of concepts is expressed in consistent way.

[sgrellet]

Hi,

“YES, what we need NOW is, to express the compatibility of concepts, and not an “in depth domain analysis of what each feature definition, attribute, association mean in both models” (this is a mapping implementation issue).” -> I disagree. In order to understand (then express) the compatibility of concepts one need to understand fully what those concepts are about. Which means each feature definition, attribute, association.

Let’s take the example of David’s question yesterday

•    Current version of Hy_Feature has a ‘HY_HydrographicNetwork’ being a aggregation of ‘HY_WaterBody’ (1..*)

•    INSPIRE has a ‘Network’ feature that can be linked to 0..* ‘WatercourseLink’ FeatureType.

But ‘WatercourseLink’’ are not at all the same beast as ‘HY_WaterBody’

ð Thus ‘HY_HydrographicNetwork’ is not the same as ‘INSPIRE:Network’’ even if they both have ‘Network’ label in their name.

However, as we said yesterday in the webconf. I fully agree that the 2D matrix is a good way to summarize this in-depth. I’m just concerned about it being the only entry for our brains when doing this comparison exercise. Otherwise we will end-up with having HY_Feature not being able to vehiculate domain meaningful information.

Sylvain

[sgrellet]

Seem our contributions forked the discussion ☺ FYI, in parallel we are setting up slots to work on this with Irina and come up with a consistent approach.

Sylvain

[rob-metalinkage]

agree with your analysis Sylvain.

I wont be at Washington :-(

... but I am willing to have a go at the more formal model mapping once we have the cartoons and the spreadsheets

(my challenge here is that I'd like to address the application schema -> OWL pathway first - in a way that produces simple OWL - as well as links it to the ISO ontology in a separate graph - so you can use the simple OWL for basic reasoning. I had a chat to Josh about this - IMHO its perhaps a month's worth of work to test latest tools like shapechange and set up some postprocessing to extract the simple view - but maybe someone is doing it already. )

I'd love to get some examples of the sort of reasoning people want to do

In my mind are quite obvious cases like "show me data products that implement a feature type equivalent to HY_Catchment and include an attribute that is equivalent (eg a SKOS?) to "soil moisture content" (using a URI from some vocabulary)

this would require reasoning over the class models, the mappings, terminology mappings and a data product catalogue.

I suspect there are other simpler, and more subtle cases people care about.

Cheers Rob

[dblodgett-usgs]

All, thanks for the lively discussion. Sylvain's A and B are helpful. We are doing A and need to try not to get distracted by B till the initial spec is atleast out for public review.

For A, I will remind everyone that this is as much a communication instrument as it is an analysis artifact. IMHO, the dataset - featuretype - attribute - association format along with a comment, which could have some formalism per @mbeaufils idea, will be much more expressive and meaningful to a reader or other consumer of the specification than a simple 2-d matrix.

Please consider developing the 2-d matrix as a simplification of the richer, multi-faceted spreadsheet.

Also, consider replying to github comments on github rather than through email. The formatting of this comment thread has become a bit tedious.

[dblodgett-usgs]

All, where are we at with creation of this matrix? I know some changes to the spec have been triggered coming out of discussions and @IrinaDornblut may be visiting BRGM to work on this, but am wondering if there are artifacts or a status update that could be registered here? Can someone be assigned as responsible to drive this task to completion?

[dblodgett-usgs]

@IrinaDornblut @mbeaufils - Bringing this back up. I'd like to propose that we spend a day working on this at the HDWG meeting. Does that make sense? Are we ready to do such an activity?

[mbeaufils]

@dblodgett-usgs @IrinaDornblut - As for now, it was not planned for me to come to the HDWG meeting. However I will be in Dublin the next week for OGC TC Meeting.

Concerning the mapping activity, I tried to keep our mapping spreadsheets up to date. I see the matrixes as final results of the mapping exercices so before creating them we will certainly have to exchange again about the mapping. @IrinaDornblut , I don't know if the idea of a visit to BRGM is still possible for you, for example in May ? This is something I have to discuss with Sylvain too.

What is more, the mapping work also raised an issue fore me as exposed in the 3rd and 4th point of my "Fresh pov" ticket. Maybe the future discussions about channel network / waterbodynetwork and flowpath could help to ameliorate this ?

[dblodgett-usgs]

Getting back to this... Could we do something as simple as:

NHDPlus Name	HY_Features Name	Comment
comid Catchment	HY_Catchment	The comid catchment is the feature that takes part in topology tables, has associated accumulated characteristics, etc.
Catchment Polygon	HY_CatchmentArea	The catchment polygon is an area realization with a polygon representation.
Catchment flowline	HY_FlowPath	The flowline associated with a catchment is the simplest case of the HY_FlowPath concept because it is one waterbody with one waterbody part.
Reachcode reach	HY_FlowPath	A reach, identified by a reachcode, is an aggregate of flowlines which can be modeled as an HY_FlowPath which is an aggregate of waterbodies each made up of one linear waterbodyPart.

[rob-metalinkage]

Sure - except perhaps flip it around - HY_first - so that all the tables will look more similar and we can repeat it. The only reason not to would be if we kept finding that multiple NHD things map to the same HY_Feature ?

On Mon, 20 Jun 2016 at 02:38 David Blodgett notifications@github.com wrote:

Getting back to this... Could we do something as simple as: NHDPlus Name _HYFeatures Name Comment comid Catchment HY_Catchment The comid catchment is the feature that takes part in topology tables, has associated accumulated characteristics, etc. Catchment Polygon HY_CatchmentArea The catchment polygon is an area realization with a polygon representation. Catchment flowline HY_FlowPath The flowline associated with a catchment is the simplest case of the HY_FlowPath concept because it is one waterbody with one waterbody part. Reachcode reach HY_FlowPath A reach, identified by a reachcode, is an aggregate of flowlines which can be modeled as an HY_FlowPath which is an aggregate of waterbodies each made up of one linear waterbodyPart.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/opengeospatial/HY_Features/issues/31#issuecomment-227006973, or mute the thread https://github.com/notifications/unsubscribe/AIR3YWApUFcZbPo1FJXf__o9PlK45z95ks5qNXCbgaJpZM4Hgs2v .

[dblodgett-usgs]

That makes sense. In the case that multiple map, I think a comma separated list or something would be fine. In the case where it's more complicated because it's a subset of a type of feature with constraints that maps or something... I think we can just type out the complication in the comment.

Looking at the overall overview figure the template would be as below. Should we add or remove anything here?

HY_Features Name	Dataset Name	Comment
HY_Catchment	..	..
HY_InteriorCatchment	..	..
HY_SimpleCatchmentNetwork	..	..
HY_DendriticCatment	..	..
HY_Outfall	..	..
HY_Divide	..	..
HY_ReferenceLocation	..	..
HY_RiverReferenceSystem	..	..
HY_IndirectPostition	..	..
HY_FlowPath	..	..
HY_CatchmentArea	..	..
HY_CatchmentBoundary	..	..
HY_CatchmentRealization	..	..
HY_HydrographicNetwork	..	..
HY_WaterBody	..	..
HY_WaterBodyPart	..	..
HY_LinearSegment	..	..
HY_WaterBodyStratum	..	..
HY_Reservoir	..	..
HY_Water_LiquidPhase	..	..
HY_Water_SolidPhase	..	..
HY_TopographicNetwork	..	..
HY_Channel	..	..
HY_ChannelPart	..	..
HY_LongitudinalSection	..	..
HY_CrossSection	..	..
HY_HydrometricNetwork	..	..
HY_HydrometricFeature	..	..
HY_HydrometricFeaturePart	..	..
HY_CartographicVisualization	..	..

[rob-metalinkage]

Maybe separate tables for catchment, topography and hydrography ;-)

On Mon, 20 Jun 2016 at 04:56 David Blodgett notifications@github.com wrote:

That makes sense. In the case that multiple map, I think a comma separated list or something would be fine. In the case where it's more complicated because it's a subset of a type of feature with constraints that maps or something... I think we can just type out the complication in the comment.

Looking at the overall overview figure the template would be as below. Should we add or remove anything here? _HYFeatures Name Dataset Name Comment HY_Catchment .. .. HY_InteriorCatchment .. .. HY_SimpleCatchmentNetwork .. .. HY_DendriticCatment .. .. HY_Outfall .. .. HY_Divide .. .. HY_ReferenceLocation .. .. HY_RiverReferenceSystem .. .. HY_IndirectPostition .. .. HY_FlowPath .. .. HY_CatchmentArea .. .. HY_CatchmentBoundary .. .. HY_CatchmentRealization .. .. HY_HydrographicNetwork .. .. HY_WaterBody .. .. HY_WaterBodyPart .. .. HY_LinearSegment .. .. HY_WaterBodyStratum .. .. HY_Reservoir .. .. HY_Water_LiquidPhase .. .. HY_Water_SolidPhase .. .. HY_TopographicNetwork .. .. HY_Channel .. .. HY_ChannelPart .. .. HY_LongitudinalSection .. .. HY_CrossSection .. .. HY_HydrometricNetwork .. .. HY_HydrometricFeature .. .. HY_HydrometricFeaturePart .. .. HY_CartographicVisualization .. ..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/HY_Features/issues/31#issuecomment-227013985, or mute the thread https://github.com/notifications/unsubscribe/AIR3YctWGLgEgGOUKdcNhAd6QsoFTSQ6ks5qNZD1gaJpZM4Hgs2v .

[lieberjosh]

Since I’m creating R2RML mappings for NHD and NHDPlus, I should be able to fill this in shortly. The mapping is a bit more complicated, though, since many NHD “features” are NHDflowline, NHDline, etc. records with the appropriate fcode value.

As far as the table, I’m not sure that there is a separate CatchmentBoundary feature with a curve segments and points in the NHD family, just a polygon geometry that represents both the (flat) area and the boundary. There is a separate DEM fragment for each catchment that would presumably be an HY_CatchmentSurface.

As far as Flowpath, it makes sense to me that it carry the edge topology of flow between whatever two outfalls are considered of interest. For the ontology, I was mostly concerned with levels of detail from scale, but a “main stem” could be another reason for a level of detail. I add “detailOf” and “detailedBy” properties to express that some Flowpaths and Outfalls add a finer level of detail to other Flowpaths. Levels of detail is not really a concept addressed by 19107. [This is one of the reasons that TIGER data ties itself in knots dealing with the lowest level of street segmentation and then struggles to re-assemble entire streets.]

I still have to revisit how to relate comid with permanent_identifier as far as minting URI”s for features, but that’s another issue of NHD vs NHDPlus and versioning.

Josh

On Jun 19, 2016, at 12:38 PM, David Blodgett notifications@github.com wrote:

Getting back to this... Could we do something as simple as:

NHDPlus Name HY_Features Name Comment comid Catchment .HY_Catchment The comid catchment is the feature that takes part in topology tables, has associated accumulated characteristics, etc. Catchment Polygon HY_CatchmentArea The catchment polygon is an area realization with a polygon representation.

Catchment flowline HY_FlowPath The flowline associated with a catchment is the simplest case of the HY_FlowPath concept because it is one waterbody with one waterbody part. Reachcode reach HY_FlowPath A reach, identified by a reachcode, is an aggregate of flowlines which can be modeled as an HY_FlowPath which is an aggregate of waterbodies each made up of one linear waterbodyPart. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/HY_Features/issues/31#issuecomment-227006973, or mute the thread https://github.com/notifications/unsubscribe/AExWhiybi48zyND-ueQW2bp36a6LK6f1ks5qNXCbgaJpZM4Hgs2v.

[dblodgett-usgs]

OK... new draft, work in progress, let's discuss

Catchment

HY_Features Name	Dataset Name	Comment
HY_Catchment	..	..
HY_DendriticCatment	..	..
HY_InteriorCatchment	..	..
HY_SimpleCatchmentNetwork	..	..
HY_Outfall	..	..
HY_ReferenceLocation	..	..
HY_CatchmentRealization	..	..
HY_CatchmentArea	..	..
HY_CatchmentBoundary	..	..
HY_CartographicVisualization	..	..

Hydrographic Network

HY_Features Name	Dataset Name	Comment
HY_HydrographicNetwork	..	..
HY_WaterBody	..	..
HY_Channel	..	..
HY_Reservoir	..	..
HY_WaterBodyPart ??	..	..
HY_ChannelPart ??	..	..
HY_FlowPath	..	..
HY_LinearSegment	..	..
HY_LongitudinalSection	..	..
HY_CrossSection	..	..
HY_WaterBodyStratum	..	..
HY_Water_LiquidPhase	..	..
HY_Water_SolidPhase	..	..

Hydrometric Network

HY_Features Name	Dataset Name	Comment
HY_HydrometricNetwork	..	..
HY_HydrometricFeature	..	..
HY_RiverReferenceSystem	..	..
HY_IndirectPostition	..	..

[dazzasmith]

David, Is this the format that you had in mind for the discussed mappings to the AHGF?

[dblodgett-usgs]

Yeah. I've started drafting some material for the NHD. Hoping to work through it with @lieberjosh and others. Total work in progress, but this is kind of what I'm thinking.

Catchment Model

HY_Features Name	NHDPlus Name	Comment
HY_Catchment	comid catchment	The comid catchment is the feature that takes part in topology tables, has associated accumulated characteristics, etc. Could also be the collection of catchment that contribute to a given reachcode reach, HUC watershed outlet, or other identifiable watershed outlet.
HY_DendriticCatment	comid catchment	Not following any diversions in the flow tables
HY_InteriorCatchment	comid catchment	catchments that do not contribute flow.
HY_SimpleCatchmentNetwork	collection of comid catchments	Including interior catchments and not following diversions in the flow tables
HY_Outfall	fromNode or toNode	NHDPlus nodes are inflow (fromNode) and outflow (toNode) nodes of a given comid catchment.
HY_ReferenceLocation	fromNode or toNode location, point location of point events, etc.	HY_ReferenceLocation can be used as a reference location for any point associated with a feature. Typically this is for outfalls and monitoring locations, but may be used for many other feature types.
HY_CatchmentRealization	Any entity that is identified by a comid	In NHDPlus, the comid identifier represents an unrealized catchment. Any geometric or topologic data that is referenced to a comid can be said to realize that catchment. This includes upstream aggregations of the network or catchment areas to form complete watersheds.
HY_CatchmentArea	Not Represented	While the polygon representing a catchment might be thought of as an area, the subset of a DEM or another land cover dataset would be more in line with the meaning of CatchmentArea.
HY_CatchmentBoundary	comid catchment polygon	The polygon representing a comid catchment should be thought of as both the catchmentBoundary
HY_CartographicVisualization	A map of a catchment	The NHDPlus dataset doesn't include any, but if a map view of a catchment is created at any scale, it could be said to be a cartographic visualization realization of the catchment.

Hydrographic Network

HY_Features Name	NHDPlus Name	Comment
HY_HydrographicNetwork	collection of flowlines and waterbodies	The collection of perrenial and ephemeral flowlines as well as so-called double line streams and on-network lakes within any collection of catchments (an HY_Catchment) can be considered it's hydrographic network.
HY_WaterBody	Perenial flowlines and waterbodies	Perenial flowlines are thought to represent water bodies as well as waterbody polygons that represent wide streams and lakes. These features indicate that there is water contained in some channel or other container.
HY_Channel	Ephemeral flowlines.	While NHD doesn't have an explicit channel concept, ephemeral flowlines can be thought of as a channel in that they indicate that water can flow there, but may not be present in the flowline container at all times.
HY_Reservoir	waterbodies that are reservoirs	Any waterbody that can be categorized as a reservoir
HY_WaterBodyPart ??	..	..
HY_ChannelPart ??	..	..
HY_FlowPath	flowlines and reaches	A flowline or reach is the linear representation of a catchment. For NHD Events, the reach is the flowpath because it is the linear element used for linear referencing.
HY_LinearSegment	flowline	For reachcode linear referencing, the reachcode flowpath is made up of a collection of linear segments that are flowlines
HY_LongitudinalSection	Not represented
HY_CrossSection	Not represented	..
HY_WaterBodyStratum	Not represented	..
HY_Water_LiquidPhase	Not represented	..
HY_Water_SolidPhase	Not represented	..

Hydrometric Network

HY_Features Name	NHDPlus Name	Comment
HY_HydrometricNetwork	Not Represented	..
HY_HydrometricFeature	event	A hydrometric feature, such as a stream gaging station, is represented as an event.
HY_RiverReferenceSystem	reachcode and measure	A reachcode reach is the river reference system's shape, the origin is the outlet of the reach, and the indirect position is the measure.
HY_IndirectPostition	measure	The measure is a indirect position of type relative position because it is a percent.

[dblodgett-usgs]

@mbeaufils and @sgrellet - We are going to need your help with the description of how INSPIRE maps. See my very rough draft above for what I'm thinking... happy to iterate on what this should end up looking like.

[bsimons14]

Hi David,

Use the <> stereotype (e.g.):

[cid:7083b44b-9c20-46da-b670-4ca19ffcfc8d]

Cheers

Bruce Simons

Research Projects Officer

CSIRO Land and Water/ Environmental Informatics E: bruce.simons@csiro.aumailto:bruce.simons@csiro.au T: +61 3 9545 2464 M: +61 475 954 391

---

From: David Blodgett notifications@github.com Sent: 22 June 2016 18:44 To: opengeospatial/HY_Features Subject: Re: [opengeospatial/HY_Features] mappingMatrix (#31)

Yeah. I've started drafting some material for the NHD. Hoping to work through it with @lieberjoshhttps://github.com/lieberjosh and others. Total work in progress, but this is kind of what I'm thinking.

Catchment Model

HY_Features Name NHDPlus Name Comment HY_Catchment comid catchment The comid catchment is the feature that takes part in topology tables, has associated accumulated characteristics, etc. Could also be the collection of catchment that contribute to a given reachcode reach, HUC watershed outlet, or other identifiable watershed outlet. HY_DendriticCatment comid catchment Not following any diversions in the flow tables HY_InteriorCatchment comid catchment catchments that do not contribute flow. HY_SimpleCatchmentNetwork collection of comid catchments Including interior catchments and not following diversions in the flow tables HY_Outfall fromNode or toNode NHDPlus nodes are inflow (fromNode) and outflow (toNode) nodes of a given comid catchment. HY_ReferenceLocation fromNode or toNode location, point location of point events, etc. HY_ReferenceLocation can be used as a reference location for any point associated with a feature. Typically this is for outfalls and monitoring locations, but may be used for many other feature types. HY_CatchmentRealization Any entity that is identified by a comid In NHDPlus, the comid identifier represents an unrealized catchment. Any geometric or topologic data that is referenced to a comid can be said to realize that catchment. This includes upstream aggregations of the network or catchment areas to form complete watersheds. HY_CatchmentArea Not Represented While the polygon representing a catchment might be thought of as an area, the subset of a DEM or another land cover dataset would be more in line with the meaning of CatchmentArea. HY_CatchmentBoundary comid catchment polygon The polygon representing a comid catchment should be thought of as both the catchmentBoundary HY_CartographicVisualization A map of a catchment The NHDPlus dataset doesn't include any, but if a map view of a catchment is created at any scale, it could be said to be a cartographic visualization realization of the catchment.

Hydrographic Network

HY_Features Name NHDPlus Name Comment HY_HydrographicNetwork collection of flowlines and waterbodies The collection of perrenial and ephemeral flowlines as well as so-called double line streams and on-network lakes within any collection of catchments (an HY_Catchment) can be considered it's hydrographic network. HY_WaterBody Perenial flowlines and waterbodies Perenial flowlines are thought to represent water bodies as well as waterbody polygons that represent wide streams and lakes. These features indicate that there is water contained in some channel or other container. HY_Channel Ephemeral flowlines. While NHD doesn't have an explicit channel concept, ephemeral flowlines can be thought of as a channel in that they indicate that water can flow there, but may not be present in the flowline container at all times. HY_Reservoir waterbodies that are reservoirs Any waterbody that can be categorized as a reservoir HY_WaterBodyPart ?? .. .. HY_ChannelPart ?? .. .. HY_FlowPath flowlines and reaches A flowline or reach is the linear representation of a catchment. For NHD Events, the reach is the flowpath because it is the linear element used for linear referencing. HY_LinearSegment flowline For reachcode linear referencing, the reachcode flowpath is made up of a collection of linear segments that are flowlines HY_LongitudinalSection Not represented HY_CrossSection Not represented .. HY_WaterBodyStratum Not represented .. HY_Water_LiquidPhase Not represented .. HY_Water_SolidPhase Not represented ..

Hydrometric Network

HY_Features Name NHDPlus Name Comment HY_HydrometricNetwork Not Represented .. HY_HydrometricFeature event A hydrometric feature, such as a stream gaging station, is represented as an event. HY_RiverReferenceSystem reachcode and measure A reachcode reach is the river reference system's shape, the origin is the outlet of the reach, and the indirect position is the measure. HY_IndirectPostition measure The measure is a indirect position of type relative position because it is a percent.

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/HY_Features/issues/31#issuecomment-227680611, or mute the threadhttps://github.com/notifications/unsubscribe/AIBi6XhP0ZCIbvXzyKsT9bqYQxWOxnLmks5qOPX-gaJpZM4Hgs2v.

[dazzasmith]

This is a WIP mapping for the Australian Hydrological Geospatial Fabric (AHGF):

Catchment

HY_Features Name	AHGF Class	Comment
HY_Catchment	AHGFContractedCatchment, AHGFCatchment	Both sets of catchments have associated topology tables showing connectivity (AHGFCatchment is facilitated via relationship to AHGFNetworkStream).
HY_DendriticCatment	AHGFContractedCatchment	Excluding subtype AHGFContractedCatchment::NoFlowArea (No outfall)
HY_InteriorCatchment	AHGFCatchment	Only instances of AHGFCatchment without a related AHGFNetworkStream and thus no outfall.
HY_SimpleCatchmentNetwork	AHGFCatchment??	Excluding instances of AHGFCatchment without a related AHGFNetworkStream and thus no outfall.
HY_Outfall	AHGFNode, AHGFNetworkNode	For AHGFContractedCatchment - nodes are inflow (FConNodeID) and outflow (ConNodeID). For AHGFCatchment - nodes are inflow (From_Node) and outflow (To_Node) nodes of a given AHGFNetworkStream feature (related to the AHGFCatchment via its DrainID. Note that for V3 prducts only, AHGFNetworkNode features have a direct relationship to AHGFContractedCatchment.
HY_ReferenceLocation	AHGFNetworkNode	HY_ReferenceLocation can be used as a reference location for any point associated with a feature. From_Node, To_Node or special subtype AHGFNetworkNode::GhostNode used for referencing Hydrometric features on the network.
HY_CatchmentRealization	AHGFContractedCatchment, AHGFCatchment	..
HY_CatchmentArea	AHGFContractedCatchment, AHGFCatchment	..
HY_CatchmentBoundary	..	..
HY_CartographicVisualization	AHGFMappedStream	AHGFMappedStream is a feature class of the Geofabric Surface Cartography product, perhaps all feature classes in this product can be considered as HY_CartographicVisualization???

Hydrographic Network

HY_Features Name	AHGF Class	Comment
HY_HydrographicNetwork	AHGFNetworkStream	Subset of AHGFNetworkStream features provides a particular HY_CatchmentRealisation.
HY_WaterBody	AHGFNetworkStream	..
HY_Channel	AHGFNetworkStream	Streams have relationship to AHGFContractedCatchment Note: FK attribution defining direct relationship to instance of AHGFContractedCatchment is currently only available in V3 products.
HY_Reservoir	AHGFWaterbody::Reservoir	..
HY_WaterBodyPart ??	AHGFNetworkStream	Streams have relationship to AHGFContractedCatchment Note: FK attribution defining relationship to instance of AHGFContractedCatchment is currently only available in V3 products.
HY_ChannelPart ??	AHGFNetworkStream	..
HY_FlowPath	AHGFLink	Note: Geofabric currently has no FlowPath for headwater area.
HY_LinearSegment	AHGFLink	..
HY_LongitudinalSection	Not represented	..
HY_CrossSection	Not represented	..
HY_WaterBodyStratum	Not represented	..
HY_Water_LiquidPhase	Not represented	..
HY_Water_SolidPhase	Not represented	..

Hydrometric Network

HY_Features Name	AHGF Class	Comment
HY_HydrometricNetwork	Not represented	Future plans are to produce a geoschematic representation of the hydrometric features at some stage.
HY_HydrometricFeature	AHGFNetworkNode::AHGFGhostNode	Ghost Nodes are a representation of Hydrometric features located on a Hydrographic Network representation. Note: Currently, V3 has a separate AHGFGhostNode feature class for ghost nodes. There are plans to include these features as part of the Hydrology Reporting Catchments product forming outfalls for AHGFContractedCatchment (HY_DendriticCatment) features.
HY_RiverReferenceSystem	Not represented	Measures are not yet explicitly included in AHGF.
HY_IndirectPostition	Not represented	Measures are not yet explicitly included in AHGF.

[dblodgett-usgs]

I'm moving these over here: https://github.com/opengeospatial/HY_Features/wiki

Going to call this issue done now that we have the format and a start on these descriptive mappings. Will open new issues for discussion of each of the three that we are focusing in on.