mexdfeje: Ejes Viales in Mexico City

[neroute2]

http://travelmapping.net/hb/index.php?sys=mexdfeje
http://travelmapping.net/user/system.php?sys=mexdfeje

I think this is ready for review. The readme has most of the info: https://github.com/TravelMapping/HighwayData/blob/master/hwy_data/MEX-DF/mexdfeje/README.md

These routes are practically the only signed routes in Mexico City, other than the D routes that serve the outskirts. They are a cross between a city grid (e.g. canmbw) and a small state (CDMX has more than half the land area of Rhode Island).

[si404]

The system abbreviation can use 'e' instead of 'eje', as it's rather long otherwise.

[michih]

The system abbreviation can use 'e' instead of 'eje', as it's rather long otherwise.

Yes!

And the system update entry is missing.
To be entered here: https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv

[michih]

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

csv entry:
mexdfeje;MEX-DF;Eje1Nte;;;;mexdf.eje1nte;
-->
mexdfe;MEX-DF;E1N;;;Eje 1 Norte;mexdf.e001n;

[neroute2]

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

I'm not sure this is appropriate. The shields spell out the abbreviations, and we have no rules about how many letters to use in file names.

[michih]

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

I'm not sure this is appropriate. The shields spell out the abbreviations, and we have no rules about how many letters to use in file names.

@yakra did start a discussion about it a while ago. We do minimum use 3-digits for route numbering. I've changed dnkpr from 2 to 3 digits because it was the only exception.

I've suggested to truncate the visible names (Eje -> E, Nte -> N etc.) and you didn't disagree. I think that the file names should follow the same policy. I don't know whether we need a rule for it, but I think it's best practice.

[si404]

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

I'm not sure this is appropriate. The shields spell out the abbreviations, and we have no rules about how many letters to use in file names.

I concur.

Arguably the directional suffix to the number could be treated like a banner?

I've changed dnkpr from 2 to 3 digits because it was the only exception.

eure is still an exception!

[neroute2]

I've suggested to truncate the visible names (Eje -> E, Nte -> N etc.) and you didn't disagree.

I do disagree...

[michih]

I've suggested to truncate the visible names (Eje -> E, Nte -> N etc.) and you didn't disagree.

I do disagree...

I could only find this: http://travelmapping.net/devel/manual/hwydata.php

The route is a concatenation of 3-digit zero-padded number designation (e.g., a005, us042, pa343, la3132), the banner if applicable (bus, trk), and the 3-letter Abbrev. if applicable (e.g., cat, pit).

The rest is not defined. I wrote what I think is best practise.

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

I'm not sure this is appropriate. The shields spell out the abbreviations, and we have no rules about how many letters to use in file names.

I concur.

Arguably the directional suffix to the number could be treated like a banner?

I could agree on a 3-letter banner.

I've changed dnkpr from 2 to 3 digits because it was the only exception.

eure is still an exception!

I know and did omit it on purpose. They are also not zero-padded. I could change it (for all regions if requested) if that's the only argument for keeping the Mexican route file names. Just let me know...

[Jim]

I generally like to keep things concise, but my preferences here are:

Use Eje rather than E.

Pad to 3 digits in filenames for consistency with (almost) everything else.

I'm not sure about using banners for the directional part.  Banners usually mean the routes are related.  Here, it's more of a street grid kind of numbering away from a city center.  I think of it more like the I-35E/I-35W cases.  I'd make them part of the route name, and have a small preference for the 3-letter abbreviations as on signage vs. single letter directional abbreviations.

[yakra]

The route names should be renamed.

File names:
mexdf.eje1nte.wpt --> mexdf.e001n.wpt etc. (3-digit route numbers, cardinal directions just one-digit)

I'm not sure this is appropriate. The shields spell out the abbreviations, and we have no rules about how many letters to use in file names.

Shields spell out both abbreviations? Got a link to GMSV of a typical shield, so we can get a better visual of what's going on?

@yakra did start a discussion about it a while ago. We do minimum use 3-digits for route numbering. I've changed dnkpr from 2 to 3 digits because it was the only exception.

Maybe you misunderstood the post. If it's the one I'm thinking of, it was more about changing from "truncate to 3" to "truncate to whatever's necessary for the system". (At the time, I was thinking of expanding out usatxl & usatxs to a uniform 4 digits, as si404 had done with gbna.)
There's another precedent for <3 digits: usanes
I could change it if there's loud enough outcry, but don't see any reason. The numerical part stands for one of Nebraska's 93 counties. I don't foresee 7 more counties being created any time soon.
Does this system have 2-digit+ route numbers? If so, Then pad.
If not? Choice is yours? There's the occasional precedent for non-padded systems. As Jim notes, almost everything else is consistently 3+.

WRT eure, si404 explained the reasoning behind why the leading zeros were originally dropped a little while back. I forget exactly why (or whether it was posted here or on GitHub) now... IIRC, something about one route actually having its leading zero signed? And there being a conflict (present, past, potential future?) with a similar-numbered route without the zero? Ack, what was it again?

I generally like to keep things concise, but my preferences here are:

Use Eje rather than E.

Waypoint labels & list names:
Seems Eje may be best? En inglés, Axis. Sounds functionally equivalent to Rd1, Rd2, Rd3, Ave1, Ave2, Pkwy1...
While alphabetic prefixes for numbered route systems have trended short overall, the manual is mum about how to handle them other than when they corresponds to a state or provincial abbreviation. Eje, serving as a generic road type, seems the best fit.
Unless -- is there a shorter, letter-abbreviation the locals use to refer to them?
Roots & filenames:
These have also trended short. Precedent for using a shorter abbreviation than the one used in waypoint labels & list names exists in usatxl & usatxs: TXLp# -> tx.lp# & TXSpr# -> tx.sp#.
OTOH, this dates back to early implementation of usansf on CHM, when guidelines in general were less solidified, and is arguably thus less worthy of consideration.
The manual does say

7. Filename root: The name of the .wpt file with the extension omitted. pa.us019trkpit, oh.oh007, etc. The filename roots are made all-lowercase and follow this formula: (Region without any hyphens) + period (.) + Route (number padded with zeroes for three digits unless the number is 100+) + Banner (if there is one) + Abbreviation (if there is one). FIXME: Some systems have 4-digit routes now.

So this means mexdf.eje#.

I'm not sure about using banners for the directional part.  Banners usually mean the routes are related.  Here, it's more of a street grid kind of numbering away from a city center.  I think of it more like the I-35E/I-35W cases.  I'd make them part of the route name, and have a small preference for the 3-letter abbreviations as on signage vs. single letter directional abbreviations.

I'll remain agnostic on whether to include the direction in the route name, or banner, (or even as a single letter) until I have a better for how these routes work, how they're signed...
Right now I'm leaning slightly toward banner, but my opinion could easily change.

[neroute2]

I'm on my phone now so I can't link directly, but the readme has street view links for shields.
I agree with adding at least one zero to the beginning, since there is a 10 Sur.
The directions are not banners; 6N and 6S are unrelated. 6N is the sixth one north of the center and 6S is the sixth one south for the center (ignoring missing routes).

[Jim]

I think one thing that helps to see the layout of these is to load up the MEX-DF regional graph in HDX.

I note that even small systems like jama that have just a handful of single-digit routes have been padded to 3.  Personally, I think it's silly to do so, but it's what we've been doing.  However, since the filenames are not visible to the end user, there's really no reason to stress too much over the file names.  We can always change them without breaking anything.  The .list names should be settled (which is where the banner part might come into play, but maybe not).

[si404]

I could change it (for all regions if requested) if that's the only argument for keeping the Mexican route file names.

I think that changing of file names of hundreds of routes (that are deliberately like that for good reason) for no other reason than to force a change to happen here is petty and silly and that it is being proposed is a strong argument for keeping the Mexican route file names as they are!

In fact, if you change the E Roads (especially the ones in my regions) to have leading zeros, I'd not only change them back to how they are now, but would go and change other systems of mine that could drop a leading zero or even 2, as they are 1- or 2-digit max (there's probably 50 systems), responding to pettiness with pettiness and undermining your desire for conformity with non-existent rules by making the convention have more exceptions...

Shields spell out both abbreviations? Got a link to GMSV of a typical shield, so we can get a better visual of what's going on?

Here's three different ones: EJE 3 OTE, EJE 6 SUR, EJE 10 SUR

Maybe you misunderstood the post. If it's the one I'm thinking of, it was more about changing from "truncate to 3" to "truncate to whatever's necessary for the system". (At the time, I was thinking of expanding out usatxl & usatxs to a uniform 4 digits, as si404 had done with gbna.)
There's another precedent for <3 digits: usanes
I could change it if there's loud enough outcry, but don't see any reason. The numerical part stands for one of Nebraska's 93 counties. I don't foresee 7 more counties being created any time soon.
Does this system have 2-digit+ route numbers? If so, Then pad.
If not? Choice is yours? There's the occasional precedent for non-padded systems. As Jim notes, almost everything else is consistently 3+.

This is what I got from that discussion. I was tempted to go and make the systems that are specifically limited to 1- and 2-digit route numbers lose their unnecessary extra digits after the discussion we had. I had assumed that dnkpr would stay the same as we'd not only formally OK'd the 2-digit numbers, but it was some effort for near-zero gains to change it. That was why I didn't change other systems - I could change it, but "if it ain't broke, don't fix it" seemed apt. However, challenging a pointless conformity that we've agreed isn't a rule would be a gain worth the effort of me changing it.

The directions are not banners; 6N and 6S are unrelated. 6N is the sixth one north of the center and 6S is the sixth one south for the center (ignoring missing routes).

Having looked at them, I've reached this conclusion too.

Though interesting that you say '6N' and '6S' - you rejected (rightly) that earlier for the file names.

However, since the filenames are not visible to the end user, there's really no reason to stress too much over the file names.

Highway Browser urls, update entries, etc.

But I agree - there's no reason to stress too much over it.

(which is where the banner part might come into play, but maybe not).

About 18 months(?) ago, I decided that the 'M' in AxM roads was functionally a banner and thus altered the .csvs to reflect that (which I think may have been how Tim did it originally - hence why they all had city abbreviations despite most not needing disambiguation). It didn't change any list files at all.

[neroute2]

Adding leading zeros: https://github.com/TravelMapping/HighwayData/pull/3383