Talk:Humanitarian OSM Tags/Humanitarian Data Model
Storing "Draft Ontology" sections removed from Humanitarian OSM Tags here for reference. Consult these when finalizing the work on the HDM, and feel free to delete when no longer necessary.
HDM page - Health Fac section organization
Might be worthy to distinguish between the HDM and the mapping between HDM and other data model for instance PAHO. PAHO is a subset of the HDM. A dedicated section can be created for this tied between HDM, data imports and osm data extracts for download-
Harmonization between HDM and guidance elements on OSM tags usages
Useful guidance elements on OSM tags usages coexist with the Table of the data model, great if we can put some work in articulating both resources the data model (listing attributes, description) and usages.
Relevance of the SAR sectors
Experts from Map Action questioned the relevance of SAR sectors which would no longer play the operational role described in the SAR section of the HDM 2.0 Common object and got replaced by the UNOCHA Pcode. They are not part of the List of core reference data set established by UNOCHA [[1]]. Consequently, I removed them from the elements composing the spatial signature of the object while checking further confirmation of this information.
SAR-sectores are mapped? where? Are there also SAR-stations? sea? land? --Markus (talk) 17:08, 22 May 2013 (UTC)
Naming conventions
For new tags (keys and values) in the HDM I suggest to follow naming patterns which are well established in OSM.
- Tag Keys
- all lower case
- can have multiple components, separated with colon (:)
- OK: addr:country, id:uuid.
- NOK: HealthFacility:Type
- Tag Values (for defined enumeration values, not for free values as allowed in name or note tag)
- all lower case
- use underscore (_) to separate word. Don't mix with -. Don't mix with dot (.). Don't use CamelCase.
- OK: health_center_with_beds
- NOK:CS-Health_center
--Gubaer 23:37, 5 February 2010 (UTC)
How to handle different phone numbers?
- Use the already defined OSM tag phone=* if only one phone number is known.
- Introduce new tags for specific phone numbers
- phone:business=* - business phone number
- phone:emergency=* - emergency phone number in the context of the HDM
- phone:mobile=* - a mobile phone number (i.e. of a ambulance)
--Gubaer 23:50, 5 February 2010 (UTC)
Mapping Operating_Organization_Type to OSM tags
Operating_Organization_Type should not be mapped to operator=* as currently proposed. operator=* should contain the name of the operating organization. For the type there could be a new tag operator:type=*. --Gubaer 00:04, 6 February 2010 (UTC)
URNs for external keys
Data modelled with HDM often refers to entities in external data set. In OSM, it is sometimes just a replica of master data managed elsewhere and merged (imported) into the OSM database periodically.
OSM currenly provides a unique technical key for OSM objects, the OSM id. The OSM is is a pair [type, number], i.e. [node, 1234567]. Such a pair uniquely identifies an object in the OSM database. The number alone is not unique. A node, a ways, and a relation might have the same number.
HDM introduces id:uuid=* to hold a unique key into an external dataset. The value of these tags should be choosen such that a XAPI query
http://xapi.openstreetmap.org/api/0.6/*[id:uuid='akey']
returns either 1 or 0 objects with this key.
We propose to use Uniform Resource Names (URN) as scheme for UUIDs in the HDM.
Example:
- Health Facilities: the unique semantic key in the PAHO dataset is a unique health facilitiy id assigned by PAHO. In OSM, we could use the URN urn:paho_health_facility_id:<id>, for instance
- Studios in Haiti: IMS provides a dataset with ~ 200 geo located radio and tv studios in Haiti. They are currently identified with a unique id assigned by IMS. In OSM ,we could use the URN urn:ims_studio_id:p123, for instance
OSM IDs as URNs
If you want to refer to an OSM object from somewhere else use the URN scheme urn:osm:<osm-object-type>:<id>.
Examples:
Type of Health Facilities
The enumeration of health facilities is first biased toward french and second biased toward the terminology in Haiti. This could be too specific for a Humanitarian Data Model targeted at modelling HDM objects in other regions too.
- CS-Health_center - CS is apparently the abbreviation for "Centre Santé", the french equivalent of "Health Center". Why not simply "Health_Center"? The OSM tags have been changed already.
- CAL-Health_center_with_beds - CAL apparently stands for "Centre santé Avec Lits", the french equivalent of "Health Center with beds". The value can be dropped. It should be combined with a new attribute "HealthFacilityBed", similar to the tag health_facility:bed=* introduced in the mapping to OSM.
- CSL-Health_center_without_beds - CSL apparently stands for "Centre santé Sans Lits", the french equivalent of "Health Center without beds". The value can be dropped. It should be combined with a new attribute "HealthFacilityBed", similar to the tag health_facility:bed=* introduced in the mapping to OSM.
--Gubaer 15:15, 15 February 2010 (UTC)
Health_center should be better "health_centre" and health_facility:bed=* should be better treat:inpatient=yes/no/only and/or capacity:bed=*. See also Proposed features/Healthcare 2.0. --Fabi2 19:42, 15 March 2011 (UTC)
- I'd concur with Gubaer. I am also confused as to the meaning of a specialist hospital. I would automatically take this to refer to one specialising in treatment of a small set of conditions (e.g., National Hospital for Nervous Diseases or the Royal Marsden, both in London). I suspect that it actually refers to regional or university hospitals (TOP hospitals in the Dutch model, CHRU in France). The terminology also misses smaller hospital types beneath the district hospital level in Western Europe): small hospitals used to be much commoner, but still exist in areas of low population in Europe and are probably pretty common in other places. The actual medical specialties practised in a hospital is presumably useful information (and often enables one to work out the category of the hospital: a hospital without anaesthetists can only offer limited types of care). SK53 (talk) 14:49, 20 February 2013 (UTC)
Draft Ontology for General Tags
Tag-Value | Description | Category |
---|---|---|
uid=* | Unique ID - combine with facilities such as healthcare facilities | General Tagging - Facilities |
government_uid=* | Unique Governmental ID - combine with facilities such as healthcare facilities | General Tagging - Facilities |
city=* | City associated with facility - combine with facilities such as healthcare facilities | General Tagging - Facilities |
ward=* | City ward associated with facility - combine with facilities such as healthcare facilities | General Tagging - Facilities |
postal_code=* | Postal code associated with facility - combine with facilities such as healthcare facilities | General Tagging - Facilities |
admin_area=* | Administrative area associated with facility - combine with facilities such as healthcare facilities | General Tagging - Facilities |
Draft Ontology for Condition Assessment
Added something on this to the discussion page osmapb1 22:08, 31 January 2010 (UTC)
These are potential road assessment tags from Nicholas Chavent using the UN Spatial Data Infrastructure for Transport - Version 2.0 (UNSDI-T 2.0) model as used by UN LogCluster, MapAction on the ground in Haiti. General note - as a first pass at making them more OSM-consistent, I removed special characters and have converted spaces to underscores; to follow existing OSM tagging model, tags and values should likely be all lower-case as well -DruidSmith
- Updated to coordinate with latest version of JOSM Presets -DruidSmith 04:28, 27 January 2010 (UTC)
Tag-Value | Description | Category |
---|---|---|
operational_status=open | Road operational - combine with operational_status_quality=* (was previously |
Road Condition |
operational_status=restricted | Road restricted - combine with operational_status_quality=* (was previously |
Road Condition |
operational_status=closed | Road closed - combine with operational_status_quality=* (was previously |
Road Condition |
operational_status=unspecified | Road operational status unspecified - combine with operational_status_quality=* (was previously |
Road Condition |
operational_status_quality=reported | Quality of road operational status information: Road operational status via report only - (see operational_status=* -DruidSmith 04:28, 27 January 2010 (UTC)) As a general thought - On IRC chat, there was some discussion as to whether or not obstacles should just be removed - Simply removing may result in confusion as those who reported the obstacle being resolved may think it inadvertently removed as opposed to understanding it as an update in status. I am wondering if there is a meaningful way to extract time when obstacle is reported as resolved -DruidSmith | Road Condition |
operational_status_quality=confirmed | Quality of road operational status: Road operational status confirmed - (see operational_status=* -DruidSmith 04:28, 27 January 2010 (UTC)) | Road Condition |
operational_status_quality=unspecified | Quality of road operational status: Road operational status unspecified (see operational_status=* -DruidSmith 04:28, 27 January 2010 (UTC)) | Road Condition |
Humanitarian:Road:Practicability=non-motorized | Suitable for non-motorized transport (was |
Road Condition |
Humanitarian:Road:Practicability=motorbike | Suitable for motorbikes (was |
Road Condition |
Humanitarian:Road:Practicability=4wd_less_than_3.5mt | Suitable for 4 wheel drive up to 3.5 metric tons (was |
Road Condition |
Humanitarian:Road:Practicability=light_truck_less_than_10mt | Suitable for light truck up to 10 metric tons (was |
Road Condition |
Humanitarian:Road:Practicability=heavy_truck_less_than_20mt | Suitable for heavy truck up to 20 metric tons (was |
Road Condition |
Humanitarian:Road:Practicability=truck_+_trailer_less_than_20mt,unspecified | Suitable for tractor-trailer combination over 20 metric tons (was |
Road Condition |
Humanitarian:Road:Practicability=Unspecified | Suitability unspecified | Road Condition |
geometry_source_type=* | Geometry source type (text field) - guidance needed -DruidSmith 04:28, 27 January 2010 (UTC) | Road Condition |
attribute_source_type=* | Attribute source type (text field) - guidance needed -DruidSmith 04:28, 27 January 2010 (UTC) | Road Condition |
Humanitarian:Road:Security=Security_Category_A | Low risk | Road Condition |
Humanitarian:Road:Security=Security_Category_B | Low to medium risk | Road Condition |
Humanitarian:Road:Security=Security_Category_C | Medium to high risk | Road Condition |
Humanitarian:Road:Security=Security_Category_D | High risk | Road Condition |
Humanitarian:Road:Security=Security_Category_E | Critical risk | Road Condition |
Humanitarian:Road:Security=Unspecified | Unspecified | Road Condition |
type=bridge_damage | Transport obstacle type: Bridge damage (was |
Road Condition |
type=road_damage | Transport obstacle type: Road damage (was |
Road Condition |
type=landslide | Transport obstacle type: Landslide (was |
Road Condition |
type=mudslide | Transport obstacle type: Mudslide (also see type=landslide -DruidSmith 04:28, 27 January 2010 (UTC)) | Road Condition |
type=debris | Transport obstacle type: Debris (was |
Road Condition |
type=checkpoint | Transport obstacle type: Checkpoint (was |
Road Condition |
type=roadblock | Transport obstacle type: Roadblock (was |
Road Condition |
type=unspecified | Unspecified transportation obstacle (was |
Road Condition |
Humanitarian:Obstacle:Practicability=Non_motorized | Obstacle passable by non-motorized transport | Road Condition |
Humanitarian:Obstacle:Practicability=Motorbike | Obstacle passable by motorbike | Road Condition |
Humanitarian:Obstacle:Practicability=4WD_3_5MT | Obstacle passable for 4 wheel drive up to 3.5 metric tons | Road Condition |
Humanitarian:Obstacle:Practicability=Light_Truck_10MT | Obstacle passable for light truck up to 10 metric tons | Road Condition |
Humanitarian:Obstacle:Practicability=Heavy_truck_20MT | Obstacle passable for heavy truck up to 20 metric tons | Road Condition |
Humanitarian:Obstacle:Practicability=Truck_Trailer_20MT | Obstacle passable for tractor-trailer combination over 20 metric tons | Road Condition |
Humanitarian:Obstacle:Practicability=Unspecified | Obstacle passability | Road Condition |
Aerial Drop Zone | Point of Access | |
Hazardous materials spill | Hazard |
Draft Ontology for healthcare facilities
Tags for health facilities attributes - these, per Nicholas Chavent are elements from from World Health Organization (WHO) CIVAS (Spatial Signature) and WHO Health Fac Shapefile structure that can be used to support the ongoing definition of the Health Tags (Attributes and values) in OSM in the course of this response.
Tag | Value | Description | Category |
---|---|---|---|
HFacOUID=* | UID | Health facility UID (country registry code) | Health Facilities |
HFacONm=* | name | Health facility official name (country registry code) Comment: How would these name tags relate to OSM name tags already in use for healthcare facilities - perhaps OSM name=* tags can be omitted and HFac name can render in place of it via Mapnik, et cetera? -DruidSmith | Health Facilities |
HFacCrtNm=* | name | health facility current name (survey) (see HFacONm above) | Health Facilities |
HFacAdr=* | address | postal address (street number, city, postal code, other; in some circumstances, a facility may have some but not all of the postal address elements and in these cases the elements that are present should be recorded; if the facility has no postal address at all, this element would be omitted) | Health Facilities |
UnitTypeNa=* | hospital | Nicholas Chavent says: Value domain of the Attribute UnitType WANTED! | Health Facilities |
ManagingAuthority=* | code | Managing authority: health facility ownership (also country-specific) with sample result codes -
code =
|
Health Facilities |
Please add to these / modify as appropriate
Draft Ontology for Other Infrastructure Useful in Humanitarian Operations
Tag | Value | Description | Category |
---|---|---|---|
man_made=* | well | Water well - "Existing Well / Newly Drilled Well / Rehabilitated Well" - pertaining to functioning wells. Potable water/contamination/capped wells should be noted as well - in some cases, wells may be viable, but capped due to lack of good pumping mechanism, to prevent infiltration and subsequent contamination. Also - see related discussion on well features here: Proposed_features/water_well | Support Infrastructure |
Draft Ontology for Identifying Sensitive Populations / Vulnerable Populations / Captive Populations
Tag | Value | Description | Category |
---|---|---|---|
amenity=orphanage | Orphanage - in OSM proposal status - see discussion here: Proposed_features/Orphanage | Special Populations | |
amenity=nursing_home | Nursing Home - in OSM proposal status - see discussion here: Proposed_features/Nursing_home | Special Populations | |
amenity=prison | Prison | Special Populations |
Standard Icons
- i would be helpfull to set standard icons on the datamodell witch should be used in poi maps. --Lübeck 19:56, 14 March 2011 (UTC)