On Wed, Oct 24, 2012 at 12:28 PM, Michal Migurski <[email protected]> wrote: > I applied these changes to OSM last night, in a series of five changesets: > > http://www.openstreetmap.org/browse/changeset/13611326 > http://www.openstreetmap.org/browse/changeset/13612265 > http://www.openstreetmap.org/browse/changeset/13612825 > http://www.openstreetmap.org/browse/changeset/13612736 > http://www.openstreetmap.org/browse/changeset/13613023 > > Offlist, I've been talking to NE2 about the edits, and he pointed out this > morning that they negatively affect shield rendering on Aperiodic: > > http://elrond.aperiodic.net/shields/?zoom=15&lat=38.7166&lon=-77.79472&layers=B > > "Whereas formerly relations with network=US:US and the modifier in the ref > failed somewhat gracefully if a bit pigheadedly (by not displaying shields at > all), they now show up incorrectly as mainline routes." - NE2 > > NE2 asked me to revert the changes, because he's unhappy with me moving the > route variant information from the ref tags to the modifier tags, e.g. > turning "ref=80 Business" into "ref=80 modifier=Business". According to the > supported tagging guidelines on Aperiodic, my interpretation should be > correct: "The value of the ref tag on the relation must contain just the > route number, without any network information." > http://elrond.aperiodic.net/shields/supported.html
This is not surprising. To give you a little bit of background... the original idea (when I drafted the material on route relation tagging) was basically to follow the convention that you followed in the remapping that got uploaded. For example, Bypass US 129 would be: network=US ref=129 modifier=bypass Somewhere along the way, it was decided that all the US networks (including the US and I networks) should start with US:, giving us: network=US:US ref=129 modifier=bypass Then there was some concern that people editing relations might "forget" the modifier - i.e. accidentally use a "US 129 Bypass" relation when tagging "US 129." Or renderers would Do The Wrong Thing if they were modifier-unaware. So two potential solutions emerged: network=US:US ref=129 Bypass or network=US:US:Bypass ref=129 with or without the modifier tag. There are technical and aesthetic arguments for and against both. The first solution correctly notes that these "modifier" networks aren't really true, distinct networks; they are local spurs or loops off the main network, so at the very least the tag "network" is a misnomer. ref is the only other tag that most mappers and data consumers will look at, so it's the logical place to put the modifier. (Using another tag instead just brings us back to the original problem that consumers or mappers might forget to set or look for it.) The second solution points out that ref was originally designed to be parsing-free for consumers - you put the content of "ref" on the shield selected from network and (optionally) modifier - and even though "network" may not be a good name for the tag, data consumers can use it as an index for the correct route marker to select without consulting other tags. Anyway, NE2 (and seemingly only NE2) favor(ed/s) the first one. Everyone else seems to have gravitated toward the second one. NE2 points to this lack of consensus and continues to do what he does. Everyone else continues to do what they do. As people go around and edit things, they get switched from one to the other (in a form of low-level guerrilla edit warfare). (Same thing has happened with ref tags on ways... same person versus the world.) Since the two forms aren't that different data consumers could preprocess data from one form to the other form. Then again having everybody do the same thing simplifies the lives of data consumers. The shield rendering team has decided to only accept the second form, for whatever reason (presumably because it makes their lives easier). As far as what to do from here... damned if I know. I don't think anyone wants NE2 banned (he's a dedicated armchair mapper and contributes a lot to OSM, even if he's somewhat pigheaded in applying his own particular approaches in places where it's not as clear he has a lot of local knowledge), but at the same time he doesn't seem to be willing to concede on this point which IMO has become an obstacle to improving the map as-used by Skobbler, Mapbox, Stamen, Cloudmade, Mapquest etc downstream. I guess my advice would be to proceed but be cautious of blowback. Chris _______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
