Feedback on Location Entity Attributes

[bahimc]

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

Attributes:

• location.level: The level the object is on, relative to other objects. Negative values are associated with underground and positive values with above ground. Zero is considered an absolute value to indicate ground level (source: OSLO). We propose to have a string field.
• location.orientation: The position of something in relation to its surroundings. We would like to ask the community about the different values for orientation or if it should be a string field.

Attributes originating from BeST Address:

• location.pointGeometry: The cartographic coordinates of a point. We propose to have a string field (e.g., Lambert08, Lambert 72 and WGS84). We propose to have a string field.
• location.municipalityName: Municipality name of the address (e.g., Knokke-Heist) (source: BeST). We propose to have a string field.
• location.adressCode: External identifier of an address (e.g., 050). We propose to have a string field.
• location.postalCode: Postal code of an address (e.g., 8300). We propose to have a string field.
• location.addressPosition: Position of a characteristic point that represents the position of the address according to some specification and includes information about the origin of the position. We propose to have a string field. Which example(s) could be used to illustrate this definition?
• location.adressRepresentationType: More readable representation with only the basic data of the address, intended for the use of an address as an attribute of another object (e.g., “Residential”, “Commercial”, “Industrial”). 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.
• location.streetName: The name of a specific street or roadway. We propose to have a string field.
• location.houseNumber: Alphanumeric code officially assigned to building units, berths, pitches or lots. We propose to have a string field. As this attribute is not always available, it would be considered as optional.

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, and with data minimization in mind, or 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]

location.addressPosition: Can you give more information on this field?

[VPiersonSWDE]

location.adressRepresentationType: What is the purpose of this field? What will be its use? How are we supposed to fill it in? Subjective by field people or objective via GIS analysis? (And if we put the field names in English, shouldn't we put addressRepresentationType? and location.addressCode?)

[VincentFeremans]

Thank you very much for commenting on location.addressPosition and location.adressRepresentationType, @VPiersonSWDE.

location.addressPosition was added due to the fact that some water companies had attributes such as "Left", "Right" or "In front" in their data models which should refer to the position of a hydrant in relationship to a hydrant.signage or other object in the vicinity of a particular hydrant. Please let us know if this attribute should be removed from the model due to irrelevance or if you agree that it is included.

location.adressRepresentationType, this attribute would provide more information regarding the area in which a hydrant is located (e.g., a "commercial area", which might indicate that there will be a lot of civilians in the vicinity of the hydrants in this area). How it should be filled in is to be decided by all group members, in case it has been decided to keep this attribute. As this is merely a suggestion, please let us know if you believe this attribute should be removed from the model due to irrelevance.

[Freddy-Theis-Zone-VHP]

Bonsoir, Comme signalé à @VincentFeremans, je ne parle pas l'anglais et je voudrais clarifier quelques points car les correcteurs ne sont pas toujours au top. Pour qu'un dispatching puisse informer au mieux les intervenants il doit savoir faire la distinction entre une bouche et une borne. Bouche: Sous le sol = Une clé de bouche, un stand-pipe du bon diamètre (80/100mm - SWDE) et un ou des tuyaux pour se raccorder à une pompe. Borne: Au dessus du sol = Une petite clé pour libérer les raccords compatible avec la vanne d'ouverture/fermeture et un ou des tuyaux pour se raccorder à une pompe.

Sur ce point, vous pouvez déjà remarquer que mise à part le ou les tuyaux, l'intervenant ne doit pas prendre le même matériel pour se raccorder à une bouche ou à une borne.

location.addressPosition: Pour moi ce n'est pas utile.

Quand j'ai développé CAOPS pour les zones VHP et WAL, j'ai privilégié l'image à la lecture d'une géo donnée. Il est plus facile de transmettre des infos en les regardant qu'en les lisant.

En résumé, les données les plus importantes sont pour moi:

• Géolocalisation précise.
• On/Off.
• Bouches, Bornes.
• Diamètre de la conduite.
• Diamètre(s) de raccordement(s).

[VincentFeremans]

Dear @Freddy-Theis-Zone-VHP , thank you for your contribution.

• location.addressPosition: If this is indeed irrelevant to the model, we propose to remove it from the model and ask other participants whether they agree with this action.

We noted down the differences between above- and below ground hydrants and we refer you to this comment, where it's addressed https://github.com/belgif/thematic/issues/132#issuecomment-1573607387

In regards to the list of most important attributes for cartography that you provided, we would like to confirm with with you that they are already included in the model. Here is a brief summary;

• Precise geolocation: This has been included in the attribute location.pointGeometry https://github.com/belgif/thematic/issues/133#issue-1691934975, which can be found above in the first post of this issue.

In the Hydrant Entity https://github.com/belgif/thematic/issues/132, you can also already find the following:

• On/off: This has been included in the attribute hydrant.status.
• Above- & below ground hydrant: As mentioned before, this has been included already in the hydrant.type attribute.
• Valve diameter: This has been included in the attribute hydrant.valveDiameter.
• Pipe diameter: This has been included in the Pipe Entity https://github.com/belgif/thematic/issues/131#issue-1691929937 under the attribute pipe.diameter.

[VincentFeremans]

Apart from the input we received from Vivaqua regarding https://github.com/belgif/thematic/issues/132, we also received attributes concerning location:

Attribute in our model	Attribute in Vivaqua's model
location.municipalityName	Commune
location.streetName	Street
location.adressCode	Zone
location.adressRepresentationType	Private

Furthermore, Vivaqua has the following attributes, which are not in our model:

• Closest address but we believe this can be included in the attributes which are already present in the model.
• Between n° and n° refers to the location of a hydrant in relation to other hydrants. We propose to have an integer field for this attribute and ask the working group whether this attribute needs to be included in the model?

[VincentFeremans]

Through Zone VHP, we received the following insights:

• location.level: As hydrant.type already grants user the information whether a hydrant is above or below ground, this proposed attribute is deemed irrelevant.
• location.geometry: Zone VHP proposes to use only one geometric system (e.g., Lambert08, Lambert72, ...). However, since participants of the first thematic workshop indicated the importance of having several geometric systems, we suggest to still move forward with the multiple geometric systems approach.

We kindly ask the working group whether they agree with these insights.

[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