---
description: notepad for the DPWH-RBI dataset mapping challenge
tags: gov.ph, challenge, draft
---

==**THIS IS A DRAFT. New content will be moved to the [OSM-PH repo](https://github.com/OSMPH/dpwh_bridges), because of new hackmd limitations for collaborators. Content will be moved to OSM wiki when details are set, or has the consensus of the community. **==

# DPWH-RBI Dataset Notepad
Mapping DPWH bridges on national highways, and conflating attributes and other inferrable data from the [DPWH Road & Bridges Inventory (RBI)](https://www.dpwh.gov.ph/DPWH/gis/rbi).

---

[toc]

---

## About
On 13th January 2022, a [Freedom-of-Information request](https://www.foi.gov.ph/requests/aglzfmVmb2ktcGhyHgsSB0NvbnRlbnQiEURQV0gtMjM2NjM0MzM2MjA4DA) with the Department of Public Works & Highways' [Road & Bridges Inventory (RBI)](https://www.dpwh.gov.ph/DPWH/gis/rbi) dataset was granted explicit permission for use with OpenStreetMap.


> For future reference, the communications with the DPWH is archived and available from the public [repo](https://github.com/OSMPH/dpwh_bridges).

## What potential value does it add to OSM?
* improve highway networks and **add/review 8,546 bridges**, including adding **load limit restrictions** (i.e. OSM's `maxweight`) for the highway segment of the bridge.
* **add/supplement highway names & other attributes** from dataset of highways connected to a bridge (i.e. value for `nat_name`, or `name` tags, `designation`, etc.)
* **improved search results**. bridges are local landmarks, and serve as practical proxies for (unmapped) settlements or waterways in the vicinity of the bridge.
* **add route number** (i.e. OSM's `ref`, if missing) for the highway.
* **address QA issues** encountered, in the course of editing a bridge/highway.
* using RapiD, casual mappers can help **validate MapWithAI highway & building detections** available in the vicinity of the bridge.

# Dataset fields

| Fields | Usable? | man_made=bridge object | highway=* object | notes |
|---|:---:|---|---|---|
| coordinates | ✔ | | | Will be used to display a map marker for a task, to visualize the location of a bridge, or starting point for a vicinity search. |
| ISLAND | | | | |
| REGION | | | | |
| PROVINCE | | | | |
| DEO | ✔ | for `operator` key | | |
| CONG_DIST | | | | |
| ROAD_NAME | ✔ | | for `nat_name`, and/or `name` key | Proposal: use `nat_name` key for the RBI highway name, and to `name` if it's empty. |
| LOCATION | | | | |
| BRIDGE_ID | ✔ | for `ref` key | | |
| BR_NAME | ✔ | for `name` key | | |
| BR_LENGTH | ✔ | for `length` key | | |
| BR_TYPE1 | ✔ | for: `material` (“reinforced concrete”,“steel”); infer `bridge:structure` | | DPWH "concrete": OSM "reinforced_concrete"; DPWH "metal" : OSM "steel" |
| BR_TYPE2 | | | | |
| YR_CONST | | | | |
| ACTUAL_YR | ✔ | for `start_date` key | | |
| CONDITION | | | | |
| NUM_ABUTT | | | | |
| NUM_PIER | | | | |
| NUM_SPAN | | | | |
| BR_WIDTH | ✔ | for `width` key | | |
| BR_LIFE | | | | |
| LOAD_LIMIT | ✔ | for `maxweight` key | | Maximum physical load limit. |
| HT_OVER | ? | | | Per Mr. Surot of DPWH Central Office, this is the physical height limit for vehicles using a truss-type bridge, measured from the deck to the height of the truss. This is not necessarily the legal height limit (i.e. `max_height`) and thererore should be used only for `max_height:physical` key. |
| HT_UNDER | ? | | | |
| L_SDWALK | ? | | infer for `sidewalk:both` ? | |
| R_SDWALK | ? | | infer for `sidewalk:both` ? | |
| NUM_LANES | ? | | maybe used for `lanes` key | Warning: OSM may already have better data |
| BNR | | | | |
| CROSSING | | | | use info to describe the task, assist for hard-to-see mapper |
| BRGY | ✔ | combine with MUN and add to: `is_in` | | |
| MUN | ✔ | combine with BRGY and add to: `is_in` | | |
| REMARKS | ✕ | | | |
| created_user | ✕ | | | |
| created_date | ✕ | | | |
| last_edited_user | ✕ | | | |
| last_edited_date | ✕ | | | |
| ROAD_SEC_CLASS | ✔ | infer for `designation` key | | |
| SEC_ID | ✕ | | | |
| SEC_LENGTH | ✕ | | | |
| ROUTE_NO | ✔ | for `ref` key | | |
| MaxBRHT | ? | | | max_height:physical ? |
| MaxPierHT | | | | |
| COMMENTS | ✕ | | | |
| n/a | | `source=DPWH-RBI` | `source=DPWH-RBI` | add or append "DPWH-RBI" as source |
| n/a | | | `overtaking=no` | highways on bridges are never overtaking zones|
# Seek LoCo consensus on:

## Bridge names on Highways
* The current LoCo bridge naming convention is to add the `bridge:name` to the highway name, with exceptions for "historical landmarks"
* This project will add additional attributes to the bridge element that is not supposed to be on the highway, therefore:
* ==**Convention amendment proposal:**== Whenever possible, draw an area to represent the bridge outline and tag it with `man_made=bridge`, then add all bridge-related properties to that element. The highway on the bridge will use the name of the connected highways, *except* when the connected highways have different names **AND** the boundary between the differently named streets are unknown, thus highway adopts the bridge name. For simple bridge mapping, or very small bridges, add `bridge:name` to the highway.
:::danger
Do not use `bridge:name` together wtih `man_made=bridge` + `name`, or it will return duplicate search results of the same bridge.
* For example
| highway=* | man_made=bridge |
| :---: | :---: |
| name | name
| official_name | loc_name
| bridge=cantilever |
| | width
| | length
| ... | ...

## Pre-processing string values

### technical terms (e.g. "Jct", "NRJ", etc.) in highway names
* Technical terms:
* "JCT" - junction
* "NRJ" - national road junction
* RCDG - Reinforced Concrete Deck Girder
* RCBC - Reinforced Concrete Box Culvert
* DPWH = "Jct Tablang-Gabaldon Road"
* OpenStreetMap tagging
* `nat_name` (and `name`, if absent) = "Tablang-Gabaldon Road", without "Jct"
* "Jct" for junction, refer to branches of the major regional highway
* Why not use `official_name` for name values? DPWH does not the have the mandate for naming highways. Local Governments have naming rights (which makes them official) for highway sections falling within their jurisdiction.

### "City" strings in highway names
* It's been observed that some contributors drop the "City" in highway names (e.g. "Ozamis-Oroquieta Road")
* should we then use `nat_name=Ozamis City-Oroquieta City Road` since this is how the dataset calls the highway, and store the normalized string as `name=Ozamis-Oroquieta Road` ?

### items in parenthesis ?
* Normalizing DPWH's "Daang Maharlika (LZ)", "Daang Maharlika (MN)", etc
* `nat_name = Daang Maharlika`
* `name:en = Maharlika Highway`
* `name:tl = Daang Maharlika`
* `official_name = Daang Maharlika Highway`
* `old_name= Pan-Philippine Highway`
* sometimes the parenthesis containers other information, (i.e. bridge structure) or some descriptive text
* example: "Amper Bridge (truss)"
* properly tagged as
* `name=Amper Bridge`
* `bridge:structure=truss`

### Spell out abbreviations ("Sn.", "Sta.", etc.)
Following OSM conventions, [abbreviations](https://osm.org/wiki/Name_finder:Abbreviations#Philippines) will be spelled out:
* "Sn." - San
* "Sta." - Santa
* "Sto." - Santo
* "Gen." - General
* "Gov." - Governor
* ...

### Roman numerals in bridge names

Example: "Santo Borys Bridge V"

Possible object name in OSM:
* [x] "Santo Borys Bridge Ⅴ" (the correct unicode character)
* [x] "Santo Borys Bridge № 5" (search friendly)
* "Santo Borys Bridge 5th" (search friendly)
* "Santo Borys Bridge V" (sic, the letter "V")
> **Recommendation**: practical to display/search using name with arabic numbers, then use name with roman numeral in alt_name. Example:
> object + `name=Santo Borys Bridge 5th` + `alt_name=Santo Borys Bridge Ⅴ`

## Capture official DPWH road class using `designation` key
* Already conventional.
* Values from DPWH `national_primary_road`, `national_secondary_road`, `national_tertiary_road`
* Potential other values: `provincial_road`, or `provincial_*_road`, or `municipal_road` or `municipal_*_road` where '*' represent 'primary', 'secondary', or 'tertiary', if known or appropriate

## Check for possible dupes

Noted by Maning (i.e. Nangka Bridge between Marikina and San Mateo, IDs: `B02865LZ`, `B01341LZ`)
> According to DPWH data `B02865LZ` is on a road with section id `S01622LZ.` While bridge `B01341LZ` is on a road section id `S03872LZ`.
> * Available Mapillary imagery shows the bridge having a 15t weight limit, 45m lenth, which matches the DPWH attributes for `B02865LZ`. There are no physical indications of two separate bridges.
> * A Mapillary [image](https://www.mapillary.com/app/?pKey=2124596877683347) shows a signage stating that you're leaving the "DPWH regional boundary". Do their engineering district boundaries match with official admin boundaries?
> * Possible dupes are hard to verify without street-level imagery (for attribute matching), or that the actual bridge is nearby.
> [name=erwin]

## Bridge span arrangement in bridge name, enclosed in parenthesis
Occassionally, a record may specify the bridge type in the name field, in a parenthesis (e.g. bridge B01118MN, "Medina Bridge(Cantilever)").

Tag as: `name=Medina Bridge` + `bridge=cantilever`

## Indistinct / Can't See / Visually unverifiable bridges
Some bridge locations are indistinct on aerial imagery. Switching aerial imagery might be helpful but it could also mean the bridge is elsewhere (anywhere between several hundred meter, to a few kilometers), or the location is incorrect.

**Recommended action**: Check the surrounding area for visual clues. OSM-compatible imagery (i.e., Mapillary, KartaView, WikiMedia, etc.) in the vicinity may be helpful, too. Skip, if no identifiable bridge is found.

Example: Bridge B01144MN is reported by DPWH at 8.2984079, 123.8463154 but is actually found at 8.3015902, 123.8466707, about 350m away.

Sometimes, the bridge name already be in OSM as `bridge:name`. Move all bridge-related tags `man_made=bridge`.
> Use CROSSING to describe the bridge, but don't add to OSM.

# Other known issues
* `maxweight` values are not consistently available. Check street-level imagery (e.g. Mapillary, KartaView, or other OSM-compatible sources) for readable values
* Ortographic/Typographic errors on names. Names (of bridge, highway) don't exactly meet expected ortography (i.e. painted on bridges), e.g. Sucat Bridge vs Sukat Bridge.
* inconsistency of extrapolated bridge `lanes` values when used to set `lanes` for connected highway. For example, a bridge is built for 4 lanes, but highway only uses 2.

# General questions

0. Is the permission letter from DPWH sufficient in form and substance to make the dataset compatible with OSM?
0. Confirm: it's possible to infer an appropriate value for `bridge:structure` ~~and `bridge:support`~~ based on the fields: ~~NUM_ABUTT, NUM_PIER, NUM_SPAN~~ BR_TYPE1.
0. According to the Wiki, it's acceptable to [combine place values](https://osm.org/wiki/Key:is_in#Tag_.22is_in.22) in `is_in`. In this challenge, is it okay with the LoCo for us to use (cleaned-up) BRGY + MUN values then?
0. Is there a more suitable option than MapRoulette for hosting this challenge?
0. To complete sub-national bridges, do we have region- or province-level LGU contacts to request a similar dataset for their geographic area?
0. Is there any risk of data quality degradation of current OSM data? If so, how can they be mitigated?

### More questions/feedback from non-public channels
* For a road name like "Mindoro Oriental/Occidental East Coastal Rd” is this two road names? I.e. Mindoro Oriental Road & Occidental East Coastal Road?
> It looks like a road named after two provinces, probably close to their boundaries. Will look into this closely. [name=erwin]
* Looks like there may be some proposed expressways in the dataset. We’ll want to be careful how that information is added or if its added quite yet.
> I didn't see this in the dataset. Will check again [name=erwin]
* Also, if bridge name is added, we’ll want to make sure it’s going in the unique bridge name tag. Its not a super common tag so I'm not sure if you are aware of it or not. (https://wiki.openstreetmap.org/wiki/Key:bridge#Naming)
> That wiki page/section doesn't mention any requirement for bridge names having to be "unique", or did I misunderstand the q? [name=erwin]

---

# Supplemental Notes /Consultation Meetings
## 2022-02-02
- Vince: This mapping project seems to require a lot of work.
> We should have a demo/workflow of how to map and tag the objects to be affected by this. [name=erwin]
- Timmy: Apart from osm.org, what other data consumers support man_made=bridge?
- [x] start page to document apps/data consumers that support man_made=bridge.
> during meeting, we quickly verified that Osmand and Organic Maps supports rendering and search for objects tagged with `man_made=bridge`. More tests [here](https://github.com/OSMPH/dpwh_bridges/wiki/Questions-and-Answers#osm-data-consumer-support-for-man_madebridge). [name=erwin]
- on changing bridge mapping convention and exceptions
- Rally: historical bridge exception. keep a list, could be reviewed again after mapping effort
- Timmy: where bridge connects highways with <u>different names</u>, the highway name should take the bridge name
- Rally: the name on man_made=bridge outline can take the DPWH name, but name variants (e.g., loc_name, reg_name, etc) can still be used in the future (i.e. renamed by local authorities)
- What if current bridge name doesn't match/disimilar to DPWH name?
> May be prefixed with `was:` (e.g. `was:name=Tulay XYZ`) lifecycyle prefix for easier review in the future, and/or explain with annotation on object? [name=erwin]
- Timmy: RBI lane count is probably outdated versus what's already OSM
- Rally: is there AI to determine whether number of indicated lanes are feasible based on road width?
- On object names:
- maybe nat_name should be as-is from DPWH, and the common name will be clean strings?
> I don't think we should keep the DPWH string names "as-is", because they won't comform to accepted OSM conventions for naming objects (e.g. abbreviations, known typos, unnecessary technical text etc.). The likelihood of DPWH using this back in their system is very low. [name=erwin]
> Also, if they wish to conflate any name string cleaning we might do, there are many easier ways to do that with various GIS/scripting tools [name=erwin]
- To minimize potential data degradation, `nat_name` is being recommended, so mappers don't inadvertently overwrite existing `name` tags added by local mappers. The value will only be *copied* **IF** `name` key is empty.
- *Example.* **DPWH: "Dumaguete North Rd (Jct Bais-Kabankalan-Negros Occ Bdry)"**
- name=Dumaguete North Road
- nat_name?
- [ ] Jct Bais-Kabankalan-Negros Occ Bdry
- [ ] Junction Bais-Kabankalan-Negros Occidental Boundary
- [ ] Junction Bais-Kabankalan-Negros Occidental Boundary Road
- [ ] Dumaguete North Road (Junction Bais-Kabankalan-Negros Occidental Boundary)
- reg_name?
- [ ] Bais-Kabankalan-Negros Occidental Boundary Road?
- *Example.* **DPWH: "Ozamis City-Oroquieta City Road"**
- `name` ?
- [ ] Ozamis-Oroquieta Road
- `nat_name` ?
- [ ] Ozamis City-Oroquieta City Road
- Timmy: we should not duplicate the values for name keys (e.g. name has the same value as nat_name, official_name, etc).
- Erwin: Redundant information doesn't improve value to OSM. Why should `nat_name` be kept as-is to directly correspond with RBI dataset?
- ==**This topic should be brought to, and widely discussed with, the OSM community**==
- Inferring `bridge:structure` per Timmy:
- if BR_TYPE1=concrete ∴ `bridge:structure=beam`
- if BR_TYPE1=Steel ∴ `bridge:structure=truss`
- Is there a civil engineer we can ask to confirm this?
- Using `is_in` on bridges
- Rally: what if bridge is located with border disputes, or between admin boundaries?
> Boundaries are mostly missing in OSM, and we don't have OSM-compatible boundary layers to determine this. The is_in tag can support multiple place names, so it's possible for disputing LGUs add their respective place names while dispute is unresolved. Example. Bgy X and Bgy Y with boundary dispute. Bridge may have: `is_in=Barangay X;Barangay Y;Municipality` [name=erwin]

## 2022-02-07
- Phone conversation with Mr. James Surot (DPWH Central Office)
- MaxBRHT, MaxPierHT -- represent physical height of the bridge from the foundation, and the pier, respectively
- HT_OVER, HT_UNDER - HT_OVER, measured in mters from deck to the to top chord. It's the physical height limit of a steel, truss-bridge. HT_UNDER is the space between the bridge (e.g flyover) and any road under it.
> HT_OVER may then be used for `max_height:physical`
> ergo, `bridge:structure` can be determined from this value? However, random testing of dataset doesn't seem to follow this consistently, nor Timmy's earlier assertion on BR_TYPE1. [name=erwin]
> Glad that Mr. Surot entertains calls and questions, but I quized him whether any dataset documentation is publicly available, and they said none is available from the DPWH website. :cry: [name=erwin]

## 2022-02-13 with LoCo
- participants: Mike, Feye, Ian, Erwin
- **Summaries**
- Meeting was recorded, and available from repo.
- **AGREED**: DPWH permission is sufficient in form and substance to use the RBI dataset in OSM.
- Feye: is DPWH aware of how OSM works, its license?
> Yes. I believe we have informed consent from DPWH. Comms history with DPWH (available from repo) will show that I explained this in detail in my earlier letters. [name=erwin]
- **No objections**:
- proceed with data clean-up
- bridge mapping convention amendment.
> We should gather more feedback on this. [name=erwin]
- present a demo challenge using subset by end of March or early April to Loco for feedback
- RBI dataset feedback
- re DPWH road name. From their Pampanga experience, the DPWH name doesn't match names set by LGUs for roads in their jurisdiction.
> Implies that using nat_name is okay, to avoid data loss for OSM highways with names. [name=erwin]
- Feye: is oneway data available from RBI? Mentions that Sakay collects satnav tracks from PUJs, which they use to help determine oneway restriction for roads.
- [x] Ian: Fix typo for `maxweight` (not max_weight) key
- [ ] double check all possible typos
### Action Items
- [x] Possible Timeline
- dataset clean-up, W7-W10
- subset demo, W10-W11
- public challenge, W11-W12
- [ ] Write down dataset clean-up rules
- [ ]
- [x] Proceed with cooperative mapping?- **No objections.**
- Mike: possible wemap revival?
- [x] Ask for volunteers. Who can help with what?
- [x] Erwin, MikeG volunteered to help with data laundering.
- [x] Feye with marketing/promotions
- [ ] Ask for volunteers in the channel
- [ ] Document project and processes on OSM wiki
- Eugene: ensure that `man_made=bridge` object nodes are connected to the highway segment with shared nodes, terminating for the bridge segment.
> Elaborate, add examples on challenge orientation docs. [name=erwin]
- [ ] Process data to create the challenge
- [x] Divvy up dataset to give more volunteers chance to contribute with cleanup
> Might be quicker than initially expected. There's only ~1100 unique road names, and 8547 bridges. [name=erwin]
- [ ] Create a small challenge (province?) to test a sub-set of tasks for LoCo feedback
- [ ] Finalize challenge, publish task
- [ ] Prepare QA checklist for post-challenge review