User talk:Worldwidewolford/HDMpresets

From OpenStreetMap Wiki
Jump to: navigation, search

Generic tags


* Values: i do not see a clear differenciation in between the 3 values; deficient sounds extremely weird

    • BW: I feel this is a strait forward classification like we had before (good, med., bad). The wording isn't ideal but this is the most used/accepted OSM tag for this.
    • NC: I think it would make more sense to have straightforward values or have (good, medium, bad) as display values.
    • SH: Agree with NC for straight-forward values. But still needs to document what we mean, as the same building / road / infrastructure won't have intuitively the same "quality" for different people
    • SM: I agree on only three categories. And yes even with only this, the thresholds will depend on the surveyors. Eg we would not rate Haitian houses the same way than Haitian people
  • Application to the object : it has to apply to more objects
    • BW: No problem. Right now it is simply applied to all objects that "status" was.
    • NCL Let's look at other objects where this tag would apply


  • Values are good>fair>deficient, we will decide for which object it applies.

Operational status and disused=yes/[no], abandoned=yes/[no]

  • disused and abandoned are too closed. If we want to simplify, we want a unique value which would equal operational_status=open/closed. I think, the disused=yes only when the feature is not in used (no matter why), this tag will not be used if the feature is in use.
  • SM: I would stay with a operational_status/used/whatsoever=yes as well because when the information is not here, you do not know if surveyors forgot (=no tag) or did not know (=unspecified or unknown). massive Operational=yes by default lack of tag would certainly lead to confusion
  • BW: I would contest this is not being used tho. Looking at our own usage that 6% of our features are tagged with closed. I think this would be better served as disused=yes. unspecified has not been utilized either enough to justify.


  • The discussion stages on this opposition with an agreement that there is no extra work (survey and editing) to tag the osm values allowing to capture operational_status=yes/no.
    • BW points out that disused=yes used in combination with source=survey shall allow for the hot export to generate operational_status=yes (all objects that are not taged disused=yes and that are tagged source=survey)



  • NC&NC: willing to maintain date
  • BW/YB?JH: against date, no way to known which value of an object refers to a date associated to the object.



  • Agreement on keeping project tags for the time being for easy reporting statistics generation, since no handy tool are available for smooth extraction of changeset tags and entering tags on changeset is not easy enough
  • Proposed tag = source:project=cap103

address= in association with any feature bearing name=

  • NC: useful when conflating with other databases looking for duplicates
  • SM: NI like the name tags used for EUROSHA presets, all coming from the map features. loc_name would allow us to create a rendering in creole, which would be quite nice. alt_name and old_name allw to inform about potential alternative or old names. Maybe short_name could be dropped , but useful for searching and recognized by nominatim, so basically a good tag


  • Address tags still exist and are encouraged. They are in a supplemental preset at the bottom of the main menu


We need to simplify access=*. yes,no,private,community,families may be redundant.

    • access=yes: open to everyone, complete access, typically implicit if no access is listed
    • no: No access what so ever? Maybe not needed, may be covered by other tags
    • private: Only with permission of the owner on an individual basis. This may cover access=no.
    • community: In what cases is this used and how is this surveyed? When and for who is this collected? When important is this to know over access=private?
    • families: same as community.
      • NC: I agree with the 3 core values above listed; I think that community can be dropped (it will be difficult to differentiate it with open=yes) but multifamilies has its place, in Senegal, Chad, you can have tap, electricity, phone that are being shared within several households.
      • SM: community would be used eg in areas where refugees are present. Some facilities may be accessible for the refugees, or for the natives, not public=for everyone


  • Add value=multifamily for an asset used/open to many households; wider community like refugees vs native, or one block vs another block in a a neighborhood are harder to figure out (more surveying expertise) and changing.


  • WS: There's been some discussion example about not using source= tags for each item, but instead tagging the changeset itself.
  • SM: yes but actually this can really bring wrong sources for some objects. Eg I trace over Bing Imagery and modify a surveyed object (eg for a type), the changeset would then be source=Bing and adios my surveyed object


  • Source is kept and for the case Sev is mentioning we will have source=Bing;Spot;survey.


  • Here's a list of humanitarian values if we want to go HDM: Mines / UXO, Roadblock, Checkpoint-official, Checkpoint-unofficial, Debris, Wreckage, Avalanche / Snow, Flood, Landslide / Mudslide, Ford, Electric lines, Trees, Rapids / Cataracts, Dam, Sand bank, Submerged rock, Road damage, Railway damage, Bridge damage, Culvert damage, Traffic restriction
    • Email thread: obstacle=check_point_unofficial
    • NC: canal-related obstacle-values:
      • waste embankments
      • various materials embankments, not sure about this one, Sev and Fred any clarification?
      • vegetation
      • others
    • SM: I would like Fred's feedback on this as he used this kind of data for the DRR survey in CS. for IOM. I as not there anymore for the post-survey


  • Consensus on adding the above values and confirmation by Fred that the preset values for canals are the good ones.
  • Needs to think and prepare canal_mapping= for the second stage of the project in 3 to 4 weeks

damage prone

  • Match our tags with Stephane's remarks


  • Re-use as much of SH tags within a plan/ scheme to map those objects in 3 to 4 weeks

humanitarian use


  • For select buildings that can be used as temporary evacuation centre and temporaray IDPs camps
  • For roads that can be used as evacuation corridors
  • health facilities so that they can scale up to a higher level in the healt system or be set to respond to a major epidemics (cholera, ebola outbreak)
  • SM: I like the idea


  • Agreement on this tag
Evacuation centres/ temporary IDPs camps
  • Objects= education, all kind of public services, places of worships, hotel.
  • Information needed:
    • is this humanitarian use official? Eg. Is this church, school registed listed as a
      • SM: sounds useful
    • hosting capacity: queried from the landuse= or the fence=
      • space
      • SM: complicated indeed to put some figures or square meters, IMHO better not to add anything regarding capacity, landuse and building surface IGS calculated + number of levers is a first rough estimation. Any official hosting purpose would need a survey made by specialists what we are not
    • Equipments: queried from surveyed objects; this implies that all below listed features are surveyed within a school
      • All Wash (watering and storage, toilets, shower)
      • Warehousing
      • Kitchen
      • Power
      • Waste management
        • SM: I agree: the objects shold be surveyed individually, not counted and tagged in the main amenity node
Health facilities
  • Objects= all health facilities.
  • Information needed:
    • is this humanitarian use official? Eg. Is this church, school registed listed as a
    • hosting capacity: queried from the landuse= or the fence=
      • space
    • Equipments: queried from surveyed objects; this implies that all below listed features are surveyed within a school
      • All Wash (watering and storage, toilets, shower)
      • Warehousing
      • Kitchen
      • Power
      • Waste management
Evacuation routes/path
  • Relation on existing road network

IDP/Refugees camp

  • NC: for a future release to be merged from old HDM and Haitian presets in correlation with camp mapping (HCR/ IOM) and practical learning from EUROSHA (Chad, Burundi)
  • SM: What do you suggest?


  • Make a proposal in the context of the yet to come camp mapping import with UNHCR; targeted time 4 weeks time.


* do we want to keep condidtion? it looks like all information which is not supported by thorough Engineers surveys are not useful

    • BW: Fine with removing this

* Tent



  • Class
    • NC: Wondering if we want to continue using service which has been left aside in the tagging values set for mapping in Africa.
    • SM: to be discussed with Pierre. IMHO service is quite specific and limited, and could be added with no big harm to the tagging roads in Africa mathodology

* Surface

    • I think we still want "ground" value
    • BW: This is fine by OSM. I think this is covered by surface=unpaved tho, and that unpaved is a more accurate, powerful classification.
    • NC I think we want to capture if this ground or if the road has been prepared with some work - see Discussion points below
    • BW: ok, yes i see the value of this, surface=*=paved for paved, unpaved for not paved but prepared, ground is ground surface with no formal preparing, and gravel
    • SH: I proposed to add "grass". If we have "ground" we can decide that it include "grass" as well.
    • NC: talking with Jaakko, we felt that it might make sense to add a sand value (no earth compacted) to the key surface, ground would imply a level of earth compaction.


  • Values are sand,ground,gravel,paved,unpaved
  • Smoothness

** This is just an impossible tag which can only lead to a lot of confusion; the 40/50 km/hour of the last preset was a neat cutt off values to assess the condition of any road stretch, I do no see it reflected here.

    • BW: Agree it is confusing but this is the OSM tag for it. I suggest we define which smoothness=* values are the cut offs for these speeds and document that in the wiki and can add that to the presets display values.
    • NC: we essentially look at good and bad around 40 kn/hours
    • BW: Agree, let's only use smoothness=intermediate/bad and define them respectively as above 40km/h and under 40km/h
    • SH: I would then add a 3rd one: good / intermediate / bad. The wiki should illustrate (pictures) what is intended with each value. For instance:
      • good=mostly paved road or very smooth surface without any major speed reduction factor. Drivers can drive up to the legal speed limit or faster
      • intermediate=badly paved road or dirt road where drivers have to drive more carefully
      • bad=road where the driving speed is hardly faster than the one of a walking person. 4x4 is necessary
    • NC: I'd rather stay on two values set around the 40km/hour, if we would like to set 3 values for smoothness, I'd suggest
      • good above > 40km/hr
      • intermediate > 5 km/hr < 40km/hr
      • bad < 5km/hr (for both 4wd and light truck)
    • BW: If you check the smoothness wiki page I believe the split of above 40 to below happens between intermediate and bad. I went with these values.
      • SM: Hmm I guess these thresholds have been set from people living in developed coutnries. For sure eg in France ,40 kmh would be considered as bad, but in Haiti 5-40 sounds to me like the speed we can hope to get on many roads. <5 reminds me some sections between Hinche and Pignon. Anyway, we really have to set speed limits otherwise the thre categories will be considered very differently between people


  • Consensus on 2 values which splits of above 40 to below happens between intermediate and bad, which can be translated into the unsdit surface_condition=good,bad.
  • Practicability
    • This attribute proved to be INSTRUMENTAL in any humanitarian logistics, the values are simple, and I thought we agreed to keep this tag in the HDM but to restrict its use when traffic over a road stretch or a transportation feature (like bridge) is restricted (eg is not passable by the more requiring transportation means a truck with trailer).
    • BW: I would definately like to limit it's use for extreme HDM purposes, and focus mainly on getting roads classified correctly. I would be for it if the keys were simplified and think the community should be involved in it's design as it's not a documented tag.
      • SM: This has to be documented because this attriute is really in use in the Humanitarian org. Eg: the Logcluster forms that is the reference (and actually designed by Nicolas when he was in UNJLC). I would not follow unquestioningly the OSM map feautres for transportation as eg the highway attributes are the most messy thing set in OSM, mixing hierarchical (primary, secondary, etc), context (residential) and physical (trunk) features, taht should be separated in sub-categories in a the best of all worlds
    • NC: As I said, its use is restricted, pls realize what it takes to get all the hum logistics agreeing and maintaining a tag, there shall be some practical knowledge into this. And this is also the role of HOT to tell the communities that in LDCs and DCs, countries in humanitarian and responses the Northern tags are not the good fit. If we are not in a position to say this, and if the whole OSM can not learn from operations in non yet mapped territories, there is something wrong.
      • BW: I'll make a practicability tag with shorter values and a wiki page for it and add this
    • NC: Jaakko and I had a discussion on this tag which we think can complete the access tag which has been used more broadly than its stric definition (restriction by law). In this view Practicability is seen as access limited or allowed by physical nature of the road. We ended up with the possible following values : practicability:[vehicule_type]=yes/no/limited/seasonal


  • Consensus on new practicability values and use when/for tagging with practicability values when traffic restriction over network (roads/ bridges/ tunnel...)
  • Footway

** It has been a longtime that we decided not to use this value anymore and rely on path since there is no way to make sure that only human will pass through a footway

    • BW: +1. What say you, Jaakko????????
    • NC: +1
    • WS: +1
  • Construction

** Consider also highway= in combination with construction=minor when/ where roads are still being used

    • BW: construction=minor. Agree for use of an optional checkbox on highways that can add construction=yes or construction=minor.
    • NC: +1 on this tag
  • Operator/Informal

** IMHO, We shouldn't use a formal/informal tag. What would be the distinction for formal/informal ? (Funded by state government ? Contracted by state government ? Those situations would likely be unclear) and I don't know what information operator:type can give that operator= can give. For 'informal' situations that I'm familiar with (Car Rapides in senegal), they'd likely be no operator tag on there. -WS

    • BW: +1
    • NC: +1 formal vs informal is really hard to distinguish, For the example car rapides in SN or tap tap in HT, shall be tagged operator=private if we deem necessary to tag them.
  • To be discussed:
    • NC: Seasonality and traffic ?
      • NC: addressed in NC and JH proposal around practicability
    • NC: Surface Preparation?
      • NC: no value in osm, surface values sand<ground<gravel<paved addresses this

**NC Is elevated?


* If we start focusing on bridge types, this list has to be completed.

    • bridge=culvert? see tunnel=culvert
    • List of values from the UNSDIT: Arch, Beam, Truss, Floating, Suspension, Culvert, Culvert - round, Culvert - box, Unspecified
    • Added:yes,culvert,arch,beam,truss,pontoon,suspension,viaduct,swing,aqueduct

Transportation means

*NC: Bus platform: I am not sure that we are interested in this one.

    • After a discussion with Jaakko, I see the use of this tag
  • other transportation means
    • amenity=taxi
    • motorcar=no
    • rickshaw=yes / bicycle=yes / horse=yes


* Aerodrome

    • We need more values for aidromes, international, national, local
    • BW: aerodrome:type=*=international/domestic/private/military??
    • NC: yes


  • add emergency=yes for improvised helipad


Water and Sanitation

  • drinking_water

** Add operator

    • Add access=yes,no,private,community,families
    • Add water supply DEFINE: What would this define?
      • NC: How water is supplied to water features; values are running water(spring,pipeline), pump, water trucking.
      • mostly not needed: springs mapped as spring, pump as well w/ pump, this feature implies tap. For water truck I think that is an option we add to our storage_tank water feature. Clear?
    • Add water purification CLARIFY: What would the values be and how would we survey them?
      • NC: this is an emergency tag (cholera); values are chlorine, osmose inverse, aquatabs, none; this would be done through specific surveys; data can be in osm, or in a umap/ ushaidi instance
    • Add condition needed? How will this be surveyed? How will it be used?
      • NC: condition shows in water tower, this shall be extended to all water objects (but spring), values are simple, interest/ outcome is for wash actors (com-gov-ngo) to be more efficient planning their surveys, fixes and setting up of new features
    • Add emergency


  • Access, emergency, condition added; purification restricted to humanitarian_use (cholera preset) and water_supply un_necessary for drinking_water
  • water_well
    • Add access=yes,no,private,community,families
    • Add water purification CLARIFY: Can water_wells be treated?
      • NC: reading from wikipedia, this is possible, I think this has to be restricted to drinking water (taps) and water storage
    • Add condition needed? How will this be surveyed? How will it be used?
      • NC: same as above for drinking_water
    • Add emergency Are their emergency water_wells?
      • NC: boreholes can be drilled quickly during an emergency phase, but this is not super common, this can be droped


  • Access, condition added; emergency and purification subject to inquiries with WASH specialists.
  • Showers

** Add access=yes,no,private,community,families

  • Toilets and latrines

** Add access=yes,no,private,community,families

  • Water canal

**NC: add covered=yes

    • NC: Add canal specific values for obstacles values for canals in the list obstacle
    • NC: Add condition only where conditions = bad

0ther Water objects

  • landuse=water_wellfield,
  • man_made=reservoir_covered, for underground/covered reservoir type=water
  • landuse=reservoir, for open reservoir reservoir_type=water_storage


  • Consensus on adding all those objects


  • Generator
    • Add emergency
    • Add condition
    • Add access
    • Add operational status/ disused=yes
  • All Power-objects:
    • Add condition
    • Add access
    • Add operational status/ disused=yes


  • Consensus on these values

Public Services

Education facilities

  • School
    • ADD Haitian values based on FR model
      • school:fondamental_first_cycle=yes
      • school:fondamental_second_cycle=yes
      • school:fondamental_third_cycle=yes
      • school:secondary=yes


  • Consensus + need to provide guidance document for documenting the values and support teaching to the team

Health Facilities

  • Hospital
    • Add below values to health_facility:type=
    • Values from WHO WorldWide DB and crosschecked with Haiti: "specialized_hospital,hospital,field_hospital,cal_health_center_with_beds,csl_health_center_without_beds,dispensary,unspecified


  • Consensus + need to provide guidance document for documenting the values and support teaching to the team

Social Facility

  • amenity=social_facility
  • social_facility:type=.....
  • social_facility:for= is really relevant for all those objects ?


  • Consensus

Commercial and Economic


  • WS: What's the difference between Tag:shop=hardware and Tag:shop=doityourself ? Do we need both tags ?
  • SM: not a difference between specialized shops (where professionals go) and the supermarket-like for general public?


  • Consensus

Physical environment


tag for rivers and streams that may be completely dry during some parts of the year. It's been used quite a bit, over 600,000 objects in taginfo. DECISION

  • Consensus
  • WS: For closed water features like lakes and reservoirs that have different levels in rainy and dry seasons, I don't know if there's a widely used tagging scheme. - WS


  • Consensus