**THIS IS A DRAFT. New content will be moved to the OSM-PH repo, 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).

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

DPWH-RBI Dataset Notepad
- About
- What potential value does it add to OSM?
Dataset fields
Seek LoCo consensus on:
Other known issues
General questions
- - More questions/feedback from non-public channels
Supplemental Notes /Consultation Meetings

About

On 13th January 2022, a Freedom-of-Information request with the Department of Public Works & Highways' Road & Bridges Inventory (RBI) dataset was granted explicit permission for use with OpenStreetMap.

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

For future reference, the communications with the DPWH is archived and available from the public repo.

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.
  
  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
  
  … …

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 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:

"Santo Borys Bridge Ⅴ" (the correct unicode character)
"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 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. 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

Is the permission letter from DPWH sufficient in form and substance to make the dataset compatible with OSM?
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.
According to the Wiki, it's acceptable to combine place values in is_in. In this challenge, is it okay with the LoCo for us to use (cleaned-up) BRGY + MUN values then?
Is there a more suitable option than MapRoulette for hosting this challenge?
To complete sub-national bridges, do we have region- or province-level LGU contacts to request a similar dataset for their geographic area?
Is there any risk of data quality degradation of current OSM data? If so, how can they be mitigated?

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. erwin
Timmy: Apart from osm.org, what other data consumers support man_made=bridge?
- 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. 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 different names, 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? 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. 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 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 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. 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.
Image Not Showing Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →
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. erwin
- No objections:
  - proceed with data clean-up
  - bridge mapping convention amendment.
    
    We should gather more feedback on this. 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. 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.
  - Ian: Fix typo for maxweight (not max_weight) key
  - double check all possible typos

Action Items

Guest Wood2022/02/06 00:26:33

Proposal: use `nat_name` key for the RBI highway name, and to `name` if it's empty.

Maybe a new "dpwh:road_name" key instead? Nonetheless, the name value should not be copied "as is" without fixing any known issues with it. But I think "nat_name" is acceptable if the community concurs. (Edited)

Guest Aguilar2022/02/06 00:32:15

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` ?

Are you expecting the mappers to do the "normalization" themselves for each case? (Edited)

Guest Malone2022/02/06 00:35:55

Normalizing DPWH's "Daang Maharlika (LZ)", "Daang Maharlika (MN)", etc

I saw a frequent variation of the Daang Maharlika road names in the dataset, where the highway section is in the parenthesis "Daang Maharlika (Agusan-Davao Sect)". Maybe "Daang Maharlika Highway" goes to name key, and drop the text inside the parenthesis? The available boundaries of region should determine where the cut-off is and should not affect the highway name itself (Edited)

Guest Hernandez2022/02/06 00:53:44

Convention amendment proposal:**==

+1 . Sounds more explicit than the old "historical landmark" exception. The "historical" importance of bridge should not be conflated with the highway **on** the bridge. The man_made bridge is rendered better on the map, and still searchable The exception when bridge connects differently named highways sounds reasonable. (Edited)

Guest Lowe2022/02/06 00:56:04

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

+1. This should be the recommended practice for place names, too. Like "Purok Ⅲ", which can be moved to alt_name, and the common name as "Purok 3" (Edited)

Guest Waters2022/02/06 00:56:46

Potential other values: `provincial_road`, or `provincial_*_road`, or `municipal_road` or `municipal_*_road` where '*' represent 'primary', 'secondary', or 'tertiary', if known or appropriate

Is DPWH providing any data about provincial or municipal roads? (Edited)

Guest Osborne2022/02/06 00:57:56

street-level imagery

Sometimes, there are detailed bridge photos available from the Wikimedia commons (Edited)

Guest McCormick2022/02/06 00:59:41

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?

Maybe "Mindoro Oriental & Mindoro Occidental East Coast Road" name is better? (Edited)

Guest Hopkins2022/02/06 01:00:05

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.

We shouldn't map or add any proposed data! (Edited)

Guest Rowe2022/02/06 01:01:07

Timmy: where bridge connects highways with <u>different names</u>, the highway name should take the bridge name

+1. This is a better exception rule (Edited)

Guest Lopez2022/02/06 01:02:33

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)

Use a unique import key (example: "dpwh:road_name") ? The downside is that it won't be indexed by search, and won't be shown on the map. (Edited)

Guest Hernandez2022/02/06 01:04:18

maybe nat_name should be as-is from DPWH, and the common name will be clean strings?

-1 . i don't think keeping it as is is good idea. why bother copying info with issues? it will only propagate more incorrect information. before adding to osm, it should remove all known issues (Edited)

Guest Potter2022/02/06 01:05:42

`nat_name

like i wrote above, maybe unique key like "dpwh:road_name" is possible, but i think nat_name is better, but do not copy as is, and remove issues first! (Edited)

Guest King2022/02/06 01:06:06

This topic should be brought to, and widely discussed with, the OSM community

+1 (Edited)

Guest Jefferson2022/02/06 01:06:56

Timmy: we should not duplicate the values for name keys (e.g. name has the same value as nat_name, official_name, etc).

+1 yes! why would you have the same value for name, nat_name, official name? i see some mappers doing that in osm, and it seems a futile effort no? (Edited)

Guest Watson2022/02/06 01:09:42

using RapiD, casual mappers can help **validate MapWithAI highway & building detections** available in the vicinity of the bridge.

yeah! +1 for recommending rapid! actually, there's a slicker fork by microsoft called Map Builder that is more noob firendly . ;) (Edited)

Guest Rios2022/02/08 08:06:28

How about: * nat_name = Ozamis - Oroquieta Road (Please take notice of the hypen with spaces to separate the place names.) * name = Ozamis - Oroquieta National Highway (Until it gets a formal/official name, how about if we add a reference to "National Highway" is very common to many casual users.) (Edited)

Guest Reynolds2022/02/15 03:02:47

"Ozamis-Oroquieta Road"

This is an example of a coordinate noun, and if you follow the Chicago Manual of Style, it recommends the use a space either side of the en dash ("–"). So, in your example this can be written instead as "Ozamis – Oroquieta Road" — it does makes sense to follow a style manual. (Edited)

Win Olario

2022/02/18 04:01:46

Following a style standard sounds good! Thank you for this idea. I'll be looking further into this. 👌 This suggested approach also handles dashes in names cleanly. For example, a road called "NJR Bah-bah-Talacogon Road". It could be clearly named in OSM as "Bah-bah – Talacogon Road" (Edited)

Timmy-Tesseract

2022/02/28 02:38:42

The orthography found in the dpwh dataset (regular dash, no spaces) matches orthography of road signs, official documents, news publications as well as local everyday usage. I think we should not modify this for subjective aesthetical reasons and stick to on-the-ground orthography. (Edited)

Guest Paul2024/05/24 13:23:56

name

dpwh davao del sur

Guest Willis2024/05/24 13:25:49

cmpd