Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Philippines route shields #195

Merged
merged 3 commits into from
Mar 10, 2022
Merged

Philippines route shields #195

merged 3 commits into from
Mar 10, 2022

Conversation

1ec5
Copy link
Member

@1ec5 1ec5 commented Feb 24, 2022

Added route shields for the Philippines.

Tacloban
Tacloban

Route relation tagging in Metro Manila is inconsistent. National routes are a mix of the oversimplified network=nhn (based on recreational route tagging), network=PH:nhn, and the network=PH:N:* found elsewhere in the country. National expressways all tagged the same way as national routes despite distinct signage. Radial and circumferential route relations lack a network tag. I’ve omitted network=nhn because it would make little sense to show these shields in Europe, where this value is endemic. I included both the other styles because it’s unclear which the community stands behind more; PH:nhn is far more common, but PH:N/E is better distributed throughout the country.

Metro Manila
Metro Manila

The Philippines handles concurrencies between national routes/expressways and Asian Highways (#122) by combining them onto a special sign. But at the size that we show route shields, it would be better to separate them into two independent shields displayed in series. Unfortunately, these concurrencies are currently tagged like ref=E2;AH26, which we can’t do anything reasonable with.

AH26/E2

@ZeLonewolf
Copy link
Member

I'm concerned about:

National expressways all tagged the same way as national routes despite distinct signage.

and:

I included both the other styles because it’s unclear which the community stands behind more

It sounds like the tagging of highway routes in the Philippines is not mature and/or lacks consensus. In #180 we removed rendering support for Swiss highway route relations for this reason. Perhaps we might consider reaching out to the Filipino mapping community to see whether there might be support for standardizing on one of the variants and also separating out relation network=* for the cases of distinct signage?

@1ec5
Copy link
Member Author

1ec5 commented Feb 25, 2022

It sounds like the tagging of highway routes in the Philippines is not mature and/or lacks consensus.

To be clear, I was describing the state of affairs in Metro Manila specifically. The rest of the country seems to be more consistent, and I only included network values that are qualified by PH:, ignoring the problematic nhn value. That said, outreach to the Philippines mapping community is a good idea. I posted to the OSM Asia Telegram chat for feedback.

@TagaSanPedroAko
Copy link

TagaSanPedroAko commented Feb 25, 2022

@1ec5 Hi there! From Philippines. but currently in Canada, I'll share what seems to be the current situation with Philippine expressway/numbered route relations.

In its current state, tagging of Philippine expressways is kind of a mess. It was in 2015 when those yellow or white shields began springing up (and have seen one since then), and one user has just began mapping those and adding relations for those numbered routes, but it kind of follows an idiosyncratic scheme of network=ph:nhn and nhn:class=expressway/primary/secondary, which is an obvious outlier. I have been bringing the network tagging into accordance with the wider network tagging scheme of [country code]:[road type] but there's hundred of these across the thousands of the Philippines' islands, let alone Metro Manila. Those should be easy to fix by the way.

@ZeLonewolf
Copy link
Member

Thanks @TagaSanPedroAko! Can you clarify which of the following network values from this PR comprise the intended tagging scheme for Philippines route relations?

PH:N
PH:N:primary
PH:N:secondary
ph:nhn
PH:E

It sounds like ph:nhn is in the process of being slowly replaced, but what is the disposition of the :primary and :secondary suffixes? Ultimately we would like to support the intended end-state tagging and not render tagging for schemes that the community intends to replace.

style/js/shield_defs.js Outdated Show resolved Hide resolved
@TagaSanPedroAko
Copy link

@1ec5 Well, relations that use PH:N:primary and PH:N:secondary should be easily migrated into the simpler PH:N, which us justifiable as there aren't much difference between the shields used for a national primary (1-2 digits) and a national secondary (3 digits).

@1ec5
Copy link
Member Author

1ec5 commented Feb 25, 2022

I don’t have a strong opinion on whether to include the primary/secondary/tertiary classification in the network value. It’s easy enough to give them all the same shield. However, if the number already reliably indicates the classification, and if you don’t think it’ll be needed for, say, a Philippines renderer that colors roads differently based on their classifications, then the plain PH:N would be simpler. As I understand it, designation is already widely used on ways to indicate the more granular classifications; I think it would be reasonable to use it in the same manner for relations.

@1ec5 1ec5 mentioned this pull request Feb 25, 2022
@TagaSanPedroAko
Copy link

TagaSanPedroAko commented Mar 9, 2022

@1ec5 Agreed. Just added various route relations last week and retagged those still using the old scheme. ph: prefix is plain wrong (that would be an ISO language code). Also removed AH26 from the main reference where tagged (those can already be covered by int_ref).

FYI, Philippines uses a road classification scheme based on function and importance, not one based on the route number or classification (as with most of Asia). Expressways, yes, will generally be motorway, but below that, it's similar with the US; 1- to 2-digit routes may not have the importance of a trunk, some 3-digit ones form the "best" routes between major cities, national tertiary is treated as an administrative classification and roads classified that best tagged by their importance. There's also a lot of bypass construction that would justify moving higher-classification roads away from built-up areas, and places like Manila and suburbs or Cebu needs to be handled differently (those very dense areas used to have even secondary roads overclassified, much like with the existing state of roads in New York or LA)

style/js/shield_defs.js Outdated Show resolved Hide resolved
@1ec5
Copy link
Member Author

1ec5 commented Mar 10, 2022

By the way, I didn’t find an existing tagging scheme for route relations for Metro Manila’s circumferential and radial roads, but those should be easy to implement once they’re tagged.

1ec5 added 3 commits March 9, 2022 17:24
This generic value requires the nonstandard, unsupported key nhn:class for disambiguating expressways, primary routes, secondary routes, and tertiary routes.
@1ec5 1ec5 merged commit a54a346 into main Mar 10, 2022
@1ec5 1ec5 deleted the 1ec5-ph branch March 10, 2022 01:34
@TagaSanPedroAko
Copy link

@1ec5 I wouldn't think circumferential/radial road numbers should be rendered at all. Well, the circumferential road numbers are in common use save C-1, but the only radial road number commonly used is R-10 (more commonly said of as Road 10). After all, those numbers are mostly for planning purposes, and there isn't a standard shield for them. I'll be in favor of rendering only AH26, national road numbers and expressway numbers; Circumferential/radial road numbers should be migrated to unsigned_ref in the route relations.

@1ec5
Copy link
Member Author

1ec5 commented Mar 11, 2022

Ah OK, that wasn’t clear from reading the English Wikipedia articles on Philippines roads, but I’ll take your word for it. Asian Highway shields are tracked in #122, but it’ll be difficult to support them satisfactorily for every country unless they have per-country network values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

3 participants