Feedback on Hydrant Entity Attributes

[bahimc]

We would like to request feedback from the community on the Hydrant entity attributes in the ICEG Data Model. Specifically, we would like to know if the following attributes for the Hydrant entity are sufficient to cater for various use cases or if there are any attributes that are missing.

Also, we have provided some values for the attributes below, but we would appreciate confirmation of the specific type of values that these attribute can take, when relevant

• hydrant.identifier: The Identifier class represents any identifier issued by any authority, whether a government agency or not. It captures the identifier itself, the type of identifier, and details of the issuing authority, the date on which the identifier was issued. (e.g., "H1234", "BEL-5678") (source: ICEG).
• hydrant.type: We would like to ask the community about the different values for hydrant types or if it should be a string field.
• hydrant.shape: We would like to ask the community about the different values for hydrant shapes or if it should be a string field.
• hydrant.flowRate: The nominal rate at which water flows through the hydrant, typically measured in liters per second (e.g., "20 L/s", "50 L/s", "100 L/s"). We propose to have a string field.
• hydrant.signage: The presence or absence of signage indicating details of the hydrant. We would like to ask the community about the different values for signage or if it should be a string field.
• hydrant.usage: The permitted usage of the hydrant (e.g., "drinking water only", "non-potable water for construction use", "firefighting use only"). We would like to inquire with the community about the range of values associated with this attribute and whether the values we have suggested are comprehensive or if any are missing.
• hydrant.startDate: Date on which the current version of the area or object starts to be used. (e.g., "01/01/2020") (Source: OSLO). We propose to have a date field.
• hydrant.lastInspectionDate: The date of the most recent inspection of the hydrant (e.g., "05/01/2022"). We propose to have a date field.
• hydrant.status: The current operational status of the hydrant (e.g., "operational", "out of service", "scheduled for maintenance"). We would like to inquire with the community about the range of values associated with this attribute and whether the values we have suggested are comprehensive or if any are missing.
• hydrant.valveDiameter: The diameter of the valve associated with the hydrant. We propose to have a string field.
• hydrant.valveType: The type of valve associated with the hydrant. We would like to ask the community about the different values for valve types or if it should be a string field.
• hydrant.geometry: Shape and position characteristics of an object (source: OSLO). We propose to have a string field.

In addition, we would like to know if the community would prefer any of these attributes to be optional or mandatory and what the cardinalities should be. We would also like to know if the community would be able to provide all the mandatory information, or, with data minimization in mind, if some of the entities and/or attributes should be stripped off.

Please share your feedback and suggestions so that we can improve the ICEG Data Model. Thank you in advance for your valuable input!

[VPiersonSWDE]

hydrant.signage:
The signalling of hydrants is a communal competence ==> On the side of producers and distributors, we do not necessarily have the information (in our case, not at all)

[VPiersonSWDE]

hydrant.identifier:
Wouldn't it be interesting to put in the identification number a specific pattern related to each owner?

[VPiersonSWDE]

hydrant.usage:
The only distinction we make is whether it's raw water or treated water.

[bahimc]

hydrant.identifier: Wouldn't it be interesting to put in the identification number a specific pattern related to each owner?

Thanks for the feedback @VPiersonSWDE. The identifier attribute is broad enough to all for different types of patterns. The Identifier data type is used in ADMS and allow for contextual information to be captured (see below).

Conceptual Model	RDF term used
identifier	content
identifier type	scheme identifier
date of issue	N/A
issuing authority	scheme identifier agency
issuing authority URI	N/A
N/A	scheme identifier version

[bahimc]

hydrant.signage: The signalling of hydrants is a communal competence ==> On the side of producers and distributors, we do not necessarily have the information (in our case, not at all)

Thank you for raising the question about the signaling attribute for hydrants. It may be worthwhile to investigate whether other group members have this data, and if not, we may recommend removing the attribute. Alternatively, if it's determined that the attribute is valuable, we can make it optional for companies who may not have this information.

[VincentFeremans]

We received input from Vivaqua regarding the attributes they report on and made a mapping with those we have already proposed to include in our data model.

Attribute in our model	Attribute in Vivaqua's model
hydrant.identifier	Number
hydrant.identifier	Hydrant ID
hydrant.valveDiameter	Diameter in CM
hydrant.status	Status of Hydrant
hydrant.type	Type
hydrant.valveType	Valve
hydrant.lastInspectionDate	Inspected on

For hydrant.valveType ("Vanne"), we received the following input: "no valve", "valve sandwich", "simpel valve", " combined valve", "unknown". We propose a code list and ask the working group whether this list is exhaustive.

However, there are still some new ones which we are researching further. We would already like to point out three of these new attributes:

• hydrant.brand: The name of the manufacturer of a particular hydrant.
• hydrant.flange ("bride"): A rib or rim for strength, for guiding, or for attachment to another object. It is used to join different sections of a hydrant, such as the main body and the nozzle or valve.
• hydrant.controlledBy: The name of the person who inspected the hydrant of performed maintenance on the hydrant for the last time.

We ask the group to let us know whether these attributes should be included in the model. In case they should be added to the model, we would like to ask the community about the different values for these attributes or if they should be string fields.

[bahimc]

Water-link provided us with input regarding the attributes necessary to document hydrants. We have created a mapping between their attributes and ours, along with suggested data types. Based on our analysis, it appears that there are two different attributes related to the status of hydrants, namely 'hydrantstatus' and 'toestand'. Additionally, the attribute 'hydrant.identifier' can accommodate multiple identifiers, including 'nummer' and 'brwnummer'. Lastly, we consider 'aard' to be a value for the attribute type. Therefore, we do not propose any changes or additions to our existing model, except for 'hydrant.valveDiameter', for which we suggest using a codelist instead of a string. Does everybody agree?

Attribute in our model	Attribute from Water-link	Range-type from Water-link
hydrant.identifier	id	long integer
hydrant.identifier	nummer	varchar
hydrant.identifier	brwnummer	varchar
hydrant.type	typehydrant	codelist
hydrant.type	aard	coldelist
hydrant.startDate	datumplaatsing	datetime
hydrant.status	hydrantstatus	codelist
hydrant.status	toestand	codelist
hydrant.lastInspectionDate	datumpaatstetoestand	datetime
hydrant.lastInspectionDate	datumlaatstestatus	datetime
hydrant.valveDiameter	diameter	codelist
hydrant.geometry	geometry	sql spatial geometrie formaat

[bahimc]

After comparing the code lists received from different sources, we have identified that 'ondergronds' (underground) and 'bovengronds' (above ground) types are the common denominators. Therefore, we will use these attributes as the basis for documenting the type of hydrants in our list. If there are additional attributes that should be included in our list, please let us know.

Water Link	Zone 4 #133 (comment)	Fluvia	Zone 2 & 3	Knokke	de Farys	Watergroep	AIEC
ondergronds	bouche	ondergronds	sous-terrain	Knooppunt	Ondergronds brandkraan	Ondergronds	bouche icendie
bovengronds	borne	bovengronds	aérien	-	-	-	borne incendie
-	-	bovengronds bemeterd aftappunt	-	-	-	-	robinet de purge

We received a set of attributes from Water Link, which include the following:

• ondergronds verder type onbekend
• bovengronds verder type onbekend
• bovengronds diameter 80
• bovengronds diameter 100
• ondergrond oude type (te ontsmetten)
• ondergronds nieuwe type volgen NBN norm
• ondergronds NBN Kort
• ondergronds NBN Lang
• ondergronds NBN Ultrakort
• ondergronds NBN Middel

Similary, we received these extra attributes from Fluvia:

• ondergronds spoelpunt

However, upon comparing the lists from different sources, we found that none of the other materials received referred to these specific attributes. Therefore, we have not included them in the mapping table. It's important to note that the attribute for diameter is captured by another attribute, which is already included in the model.

[VincentFeremans]

Concerning 'hydrant.status', we received only the following values. AGSO Knokke-Heist and IWVA only use "in gebruik", while Farys also uses the value "tijdelijk buiten bedrijf" in addition to the similar value "in bedrijf". Moreover, Pidpa follows a similar approach with "Bruikbaar" and "Niet Bruikbaar" but also provides status types such as "Ontoegankelijk" and "Bruikbaar met opmerkingen". In case of the latter, offers Pidpa the possibility to indicate which defects/problems a certain hydrant has. This information is then shared on maps as well.

AIEC, on the other hand, uses a different approach for stating the operational status of a hydrant through "excellent","bon", "mauvais" and "à remplacer". Please note that this analysis is based on actual data received, and it may not cover all potential pipe statuses.

Furthermore, Water-link presented an even more extensive list:

• Open
• Defect open (AWW)
• Verlaten
• Opgevuld
• Uitgenomen (in ontwerp)
• Defect open (BRW)
• Defect toe (AWW)
• Defect toe (BRW)
• Werken in uitvoering
• Defect Open (dringend)
• Defect Toe (dringend)

Although we have observed different values in various models, we are confident that they can be mapped to the initial proposition mentioned in #132 (comment): "operational," "out of service," and "scheduled for maintenance".

We would appreciate it if you could confirm whether these three attributes are exhaustive for a code list on hydrant.status, or if additional values are needed.

Lastly, we noticed that Pidpa also has an attribute called hydrant.inspectionStatus. However, we believe that the attribute hydrant.status already encompasses this.

[VincentFeremans]

We noticed that there is are some participants who measure hydrant.flowRate differently using different units (e.g., L/s , L/min, m3/h, ...).

We ask the working group whether L/min is the best unit of measure for this attribute or whether another one must be used (e.g., m3/h)?

Furthermore, Zone VHP indicated the irrelevance of the attribute hydrant.signage, due to which we recommend to remove this from the data model. If anyone disagrees, please let us know.

Lastly, Zone VHP also proposed the attribute hydrant.openingKey ("clé de manoeuvre") with the following values:

• 20 mm
• 30mm

Since we have not seen this attribute anywhere else, we ask the working group to let us know whether this should be included into the model and if so, whether it needs to be a code list or a string.

[VincentFeremans]

hydrant.flange ("bride"): A rib or rim for strength, for guiding, or for attachment to another object. It is used to join different sections of a hydrant, such as the main body and the nozzle or valve.

As we are investigating all elements of a hydrant which are of importance, we would like to ask once more whether the "flange" (bride) is of value to insert into the data model.

[VincentFeremans]

We received some interesting insights regarding the valve of a hydrant. In the model used by AIEC, a valve is an entity on itself with the following attributes:

AIEC data model
Situation
Location
Status
General position
Opstream flow (source, CE reservoir, etc.)
Downstream flow
Handling impact (streets impacted if closed)
State
Handling
CV status if CV
Comment
Photo

However, we will not include these attributes in our model and create a separate entity for valve at this moment. We do ask the working group to inform us in case some (or all) of these attributes should indeed be documented in our model.

Furthermore, Zone VHP highlighted that we should include the attribute hydrant.exits to our model which refers to the hydrant outlets.

Value examples for hydrant exits/outlets:

• "2x Ø70mm + 1x Ø100mm"
• "2x Ø65mm"
• "1x Ø80mm + 2x Ø52mm"
• "3x Ø75mm"
• "1x Ø100mm + 1x Ø150mm"
• "2x Ø80mm + 1x Ø125mm + 1x Ø150mm"

As far as we understood, no other organisation specifically pointed out these "outlets". We therefore ask the working group if the attribute of "diameter" is mentioned in a data model, it then refers to this element or to the valve of a hydrant? We also ask the working group whether hydrant.exits should be included into the model and whether this list of values is exhaustive enough? If so, we propose to have a code list.

[VincentFeremans]

hydrant.controlledBy: The name of the person who inspected the hydrant of performed maintenance on the hydrant for the last time.

After further analysis, this attribute will not be documented in the model as the employee who performed this action is of lesser importance to our model and only of internal importance for water companies . The main focus for our model lies on which organisation operates a certain hydrant. Please let us know in case any of you disagree with this comment.

[VincentFeremans]

During the first thematic workshop, it was indicated that "Open Water" should also be included into the model (under hydrant.type). However, we received a model from Fluvia in which Open Water is an entity on itself:

Overview of the most interesting attributes
Open water Type
Large water transport name
Name_institution
Approach route
Installation location
Reachable with
Estimated amount
Reliability
State of the open water

We kindly ask the working group to let us know if Open Water can be mapped under `hydrant.type or if it should be a separate entity? Furthermore, if it should be a separate entity, please inform us whether these attributes related to open waters should also be included into the model and if they are exhaustive. We thank you in advance.

[cdemoor]

Open Water - is not a hydrant - it will have different attributes, so it's more logic to see it as a different feature. (naturally you could make it one by adding a type with possible values 'Open Water' and 'Hydrant' - disadvantage is then several attributes empty depending on this type) I would choose for 2 different features.

[cdemoor]

Avoid names of persons else GDPR will apply, contacts can be phonenumber , emailaddres, servicename (companyname)

[cdemoor]

I see for status , you indicate operational , out of service, scheduled for maintenance.
My question if only for fire-departments , quality of water isn't relevant, but for other
emergency services, i would understand to know if water is drinkable or not can be useful.

[cdemoor]

If all this data is brought to one platform - also to talk about is, frequency en format of data exchange. and for actual status do you want for example a rest-service so this can be requested and verified real time ? (think about a unique key of the hydrant then) or use of wms / wfs with color-symbol to know actual status (use OGC standards for exchange of data)

[VincentFeremans]

We have initiated the public review of the ICEG Hydrants model. We appreciate all the feedback we received within this conversation and want to notify that everything has been addressed in the model, which can be accessed via the following link: https://belgif.github.io/thematic/models/hydrants/index_en.html

We advise you to review the model internally and welcome any final adjustment requests or suggestions you may have.

Kind regards,
The ICEG Hydrants Team

[thirions]

FireHydrant
HydrantType (=soort)
• Above ground
• Rinsing point --> Are hydrants with type 'spoelpunt' useful in final datasets?
• Under ground
• Wall mounted --> Not used by De Watergroep

Identifier
• OK (=G3E_FID)

FlowRate
• Not possible to provide this information

Status
• OK (=status)

LastInspectionDate
• Data not yet available for De Watergroep
• In scope in Enterprise Assetmanagement project

StartDate
• OK (=plaatsingsdatum)

Geometry
• OK

OpeningKey
• OK (= 20mm)

StatusRemark
• Not mandatory

Address
• Not Mandatory = OK

Outlet
• OK

Valve
• OK