Re: [Talk-us] MapQuest Open Maps now has proper state shields
I like the fact that they took some artistic license and used "stylized", or "iconified" shields, rather than trying to do a perfect pixel-per-pixel resize of the prototype shields. The latter method does not necessarily produce good on-screen results. (Which is to be expected, given that the prototype shields and fonts were designed for reflective lighting at sizes on the order of feet, rather than emissive lighting at sizes on the order of millimeters.)Case in point...maybe it's just my twisted mind, but...when I look at the Indiana state route shield at http://elrond.aperiodic.net/shields/, I see "DOGMAN" instead of "INDIANA" if I'm more than about two feet from my screen. :) Compare that to MQ's version, where they apparently think that using a square is "good enough", and do not try to reproduce the "INDIANA" legend or use the FHWA font for the digits.There is a balance there somewhere, between being too stylized while still having a level of realism that satisfies us road geeks who can spot the difference between FHWA Series C and D characters that are a few pixels in size. Personally, I think Google's Interstate shields are too stylized (the blue color they use is horrible) as are their US shields (which almost look like plain old circles); MQ seems to have struck the right balance of size and detail. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
Chris Lawrence : > modifier=* would represent MUTCD-type banners attached to the shield This is the first I've heard of this tag. I don't recall it being discussed when we were hashing ideas around on this last summer. (Not that that is reason to discount it.) But what came out of that discussion was the following guidance: "ref" will store "the unique identifier within a particular classification", where "particular classification" is stored wholly in the "network" tag. So, "network=US:US:Business"/"ref=13" and "network=US:US:Truck"/"ref=70" both conform to that definition. "network=US:US"/"modifier=Business"/"ref=13" does not. Are "US:US:Business" and "US:US:Truck" "true" networks? Perhaps not. Would it be "correcter" to separate "truck" and "business" into other tags? Perhaps. Is storing "business" and "truck" within the "network" tag causing confusion for data consumers and not a workable solution? Doesn't look like it from the proof of concept renderer posted on here. Chris Lawrence : > That said it may be easier to combine modifiers/banners into the > network as subtypes. Renderers can fallback to the longest > left-anchored substring they understand for weird things they don't > understand. > Whatever folks want to do (including modifier -> banner) > would be fine with me; it's not like there are thousands of relations > that would need to be changed to the consensus that emerges. Agreed...good points. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
Phil! Gold : > It seems to me that network=US:US:Business:MD is the logical extension of > a scheme that has US:US and US:US:Business. My initial reaction is that this goes too far in mixing geographic, classification, and rendering concepts, which has a bad smell: * It forces one to state explicitly what is already available implicitly somewhere else: if a renderer wants to display a Maryland-specific US Business shield, then it can already do so by determining whether the point at which the US:US:Business shield is to be rendered is within MD. Alternatively, the renderer could look for a "responsible agency" or "owning agency" style tag. (I don't even know if such a tag exists, admittedly.) * It forces mappers to have knowledge of which agencies use non-standard shields, so that they can break the relations at those agencies and add the agency-specific tag. (Whereas, where agencies use the "standard" shield, relations can stretch over agency boundaries.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
Nathan Edgars II : > It seems that many people see the network tag as not representing a > network but a shield design. Does this sound accurate? No, because, where shield designs differ by agency for the same logical network classification, the network tag does not change, despite the differing shields. One of many examples: Maryland uses a unique green-on-white shield for US Business routes, but those roads still get tagged as "network=US:US:Business", not "network=US:US:Business:MD" or somesuch. The renderer would have to detect which agency the road is "in", and render the agency-specific shield accordingly. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Relations and Special (Bannered) Routes
This was discussed in the August 2011 thread, "Use of ref-tag on state highways". At the time, a number of people seemed to be on board with the "network-classification-per-banner" scheme, as in: network=US:US:Alternate ref=1 Or, something similar at the state level: network=US:VA:Secondary ref=7100 I think all that really remains is to formalize/define the valid values for the various federal- and state-level "network" tags in the wiki. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Medians and reverts
>> [Richard] Clearly these evil paint-separated commuter lanes are a gateway >> way to one-area-per-lane micro-mapping. [...] > [Paul] I'm not seeing how the slippery slope argument applies [...] Nor am I. Choosing to model distinct, disparate, and incompatible traffic flows as a single flow when they are separated by paint, but as discrete flows when they are separated by anything other than paint, strikes me as an inconsistency for a traffic flow model. I'd also like to defend the concept of a single-way-per-lane model as a noble goal rather than a pedantic endeavor. There are useful concepts that I'd like to convey that I cannot, due to the current multiple-lanes-per-way model. While acknowledging the cost (in time and effort) of implementing it, I'd submit that a single-way-per-lane model is the penultimate model of traffic flow. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Medians and reverts
Paul Norman > I would not separate a road with a double-yellow in the middle into two > separate ways And millions of miles of two-lane roads with opposing flows have been modeled in OSM as single ways. But why? I'd submit that it's because the current de facto usage of ways is to model "contiguous areas of improved driving surfaces", not "traffic flows". To prove my point, if I milled out a one-foot wide swath of asphalt where the double yellow lines are to create a "median" consisting of nothing other than dirt, but changed absolutely nothing else in regards to the traffic flows, I'd suddenly be expected to model this in OSM as two discrete ways. All I've done is replaced paint with dirt. I've changed nothing in regards to the legality of transferring between the flows (paint or median, I still am not allowed to transfer between the flows). I've changed nothing about the physical ability to transfer between them (I can drive over a patch of dirt as easily as I can drive over a stripe of paint). Yet I've changed how I model them. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Medians and reverts
What to model as discrete ways has always struck me as a gray area in the OSM model. I'm of the opinion that, at locations where traffic may not or can not transfer from one linear flow to another, the flows should be modelled as discrete ways. The reason for the inability to transfer between flows should not be a determining factor in deciding what to model as separate ways. If I can't transfer between flows, I want to know that; whether the reason for being unable to transfer is stripes of paint or a 10 foot tall concrete barrier or a median of weeds and dirt is not germane. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] REST Services
The county must be running ESRI stuff on their back end, which is why they are exposing their data via ESRI's REST API. That would also explain why their imagery is supported in ESRI's tools. JOSM would need to support this ESRI REST API in order for you to consume the county's data. If JOSM doesn't already have this support baked in, it may be able to be added to JOSM via a plugin. That might be a worthwhile endeavor if a lot of agencies are starting to publicly expose their data via this API. By the way, if I recall correctly, JOSM uses another ESRI API for USGS imagery, which is based on XML web services (which is way more complicated and verbose than REST). So if JOSM is able to use that ESRI API, I have to think support can be added for this other one. But I'm nary the JOSM expert. Is there a JOSM mailing list? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
I tend to think of business, truck, loop, alternate, etc. as logical subnetworks, or sub-classifications, of their respective networks. Just a different way of thinking, I suppose: "50" is the unique designation within the "Business" sub-classification of the "US Highway" network (i.e, US:US:BUS) as opposed to "50 Business" is the unique designation within the "US Highway" network (i.e., US:US) I see what you're saying about Arkansas, in that their treatment of US business routes on signage "feels" more like a "different designation". On the other hand, Maryland uses a totatally different shield design for business US routes (basically a green-on-white US shield), which is more of a "distinct network" feel. Either scheme allows data consumers to differentiate business and non-business networks, but we probably ought to standardize on one or the other. Original Message Subject: Re: [Talk-us] Use of ref-tag on state highways From: Nathan Edgars II Date: Wed, August 24, 2011 6:37 pm To: talk-us@openstreetmap.org On 8/24/2011 6:25 PM, Craig Hinners wrote: > FWIW, I agree with all of Jason's suggestions, below, for the > relation-level "network" tag values. It mirrors my thinking on the > matter exactly. I disagree with putting alternate and business in the network. These modifiers are part of the designation, and some states (Arkansas in particular) treat them as lettered suffixes rather than separate plates. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
FWIW, I agree with all of Jason's suggestions, below, for the relation-level "network" tag values. It mirrors my thinking on the matter exactly. Original Message Subject: Re: [Talk-us] Use of ref-tag on state highwaysFrom: Jason StraubDate: Wed, August 24, 2011 3:37 pmTo: "talk-us@openstreetmap.org" As the person that just got done labelling each TX state highway, I'll chime in here with some comments.For the network tag, I think that the labelling should be (country : state network : network within the state : subnetwork in state), while the ref is JUST the number for that highway. So:US:I -> InterstateUS:I:BUS -> Business InterstateUS:US -> US RouteUS:US:BUS -> Business US RouteUS:US:ALT:BUS -> Business Alt US RouteUS:TX -> Texas State HighwayUS:TX:FM -> Farm to MarketUS:TX:RM -> Ranch To MarketUS:TX:FM:Bus -> Business Farm to Market Having been through most of the highways in TX at least, this works for all that i've labelled, whether it's still that way or not. I prefer to have the final labels show the state abbreviation and number (TX 10) instead of generic state labeling (SH 10) (TX has state highways, not state routes), but am willing to work with either. Once a useful mapping tiling appears that uses state shields, this wont matter nearly as much.Jason25or6to4>network=US:TX:SR>ref=10>= Texas State road 10>network=US:FL:Orange:CR>ref=10>= Florida Orange county road 10>network=US:TX:FARM>ref=10>= Texas State Farm road 10>Wouldn't this just use one US in network?>network=US:BUSINESS>ref=50>= US Business 50 ___Talk-us mailing listTalk-us@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
> Alan Mintz alan_mintz+...@earthlink.net > For FM 1960, I'd use:> network=US:TX> ref="FM 1960" I'd prefer to put all of the network information in the "network" tag, keeping the "ref" tag as a pure container for "the unique designation within the network": network=US:TX:FARM ref=1960 Similarly, instead of this style of tagging of US business routes (example found in Salisbury, MD): network=US:US ref=50 Business I'd prefer: network=US:US:BUSINESSref=50 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] GPS overreliance anecdotes (WAS: Women trust GPS, drive SUV into Lake)
Reminds me of when, on the first day of a new job, I accepted a ride with my new co-worker to join others at the traditional "lunch with the new guy". He didn't know the way to the restaurant, but I did, having checked OSM prior to leaving. No matter, he insisted on obeying his GPS and ignoring me. I bit my tongue, what with being the new guy and all. Three wrong turns, two missed expressway exits, and one illegal u-turn later, we arrived at the restaurant. Fifteen minutes late. I should have taken that as a harbinger of things to come; to wit, the job only lasted a few months. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] REF tags for State Highways on ways
So it's clear from the responses that there are differing needs here: Due to regional differences, displaying the two-letter USPS code in the shield is not necessarily desirable. For example, there are states where "SR" is more easily understood. At the conceptual level, the same string should not be used to represent the networks of multiple states, and some state-unique ID, be it the USPS two-letter abbreviation or otherwise, is needed. Currently, the "ref" tag does double duty for both conceptual and rendering level concerns. That's the root cause of the problem here, and will continue to be, until the conceptual-level data is moved out of the "ref" tag into its own tag(s). There is nothing stopping anyone from tagging state highways with conceptual-level tags this instant. One could, say, add "highway:network:us:fl=123" tags to Florida state highway 123, leaving the ref tag as "SR 123". Map users see something they're familiar with ("SR" instead of "FL"), and automated agents of OSM data get a unique key to identify the concept of "that network of highways in the US state of Florida". It's a win-win. Of course, it would be desirable to have consensus on the syntax of the conceptual-level tag, be it "highway:network:us:fl=123", or "highway:network=us:fl:123", or "highway=fl:123", but that's a diversion from the crux of the issue, which is the overloaded use of the "ref" tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relations, cycle routes, shapefiles
>[The "rich key" methodology] still can't handle ways that are part of more than one route (e.g. situations like the I-580, I-80 overlap are actually fairly common).It can, using semicolon-delimited values. Your example becomes:highway:network:us:interstate=580;80As an aside, if OSM didn't have the limitation (or benefit, depending on your point of view, I suppose) of not supporting identically-keyed tags on the same object, I'd prefer to use multiple tags with the same key [on the same way]:highway:network:us:interstate=580highway:network:us:interstate=80 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relations, cycle routes, shapefiles
Sure, relations get you an additional degree of normalization. And using relations to carry route/network tags gets the job done, granted. But at what cost?I've yet to hear a convincing argument that justifies the additional complexity of relations as they are being championed as carriers of route/network tags, nor have I heard why applying tags with highly-specific keys directly to ways is so fundamentally flawed that it warrants the added complexity of relations.As if to prove my point, the whole reason this thread even exists (if my understanding is correct) is that those who are trying to import data from other GIS formats (Shapefiles) are being stymied by the fact that the tags-to-relations-to-ways model turns a non-trivial task into a head scratcher.So, what this tells me is that, while insistence on a one-relation-per-logical-route methodology results in a normalized, one-to-many schema, it creates an artificial barrier for those seeking to add data to OSM. I, for one, will gladly accept the tradeoff of not being able to trumpet the fact that my dataset is "normalized" in return for lowering the barrier for others to enrich the map.If I had my way, I'd tell these people to forget about relations and simply tag the ways that comprise the cycleways with tags like cycleway:oregon=3A, cycleway:oregon=9, cycleway:oregon=Sunset Ridge Trail, etc., and be done with it. (I have no clue whether those are legitimate route numbers/names for cycleways in Oregon; I'm just using them to illustrate a point.)And, unlike the current situation of keys-that-aren't-really-keys, cycleway:oregon represents one concept, and one concept only: cycleways in Oregon. Unlike, say, a "ref" tag, you won't find it on cycleways in Ohio, or highways in Ottawa, or bus routes in Oslo, or oil pipelines in Oman. Want a map of the Oregon cycleway network? Hello OSM API, give me all the ways with tag.key==cycleway:oregon. Want to render the Oregon cycleway shield? Do so if the tag.key==cycleway:oregon and put the tag.value in the shield. No parsing...no additional DB JOINs...no collisions with other tags on the same way. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relations, cycle routes, shapefiles
The only thing that relations add (in terms of tagging) is an order of magnitude of complexity.There is no technical reason why direct application of tags to ways can't work. However, this requires the use of highly-specific tag keys, such as a unique key for interstate highways, a unique key for U.S. highways, a unique key for [insert your state here] highways, a unique key for [insert your state here] bikeways, etc.For whatever reason, though, the de-facto practice became cramming everything under the sun into the values of tags having non-unique keys, such as ref, to the point where said tags mean everything while at the same time mean nothing.The concept of key/value pairs is common in computing, where the key describes a unique concept in the dataset: interstate, U.S. hwy., etc. However, now that ref has taken on thousands of different meanings depending on context, it can hardly be considered a "key" any more, to where it has zero utility outside of rendering (i.e., displaying its value in a "shield"). Which is quite ironic, if you think about it, given how we're constantly berated to "not tag for the renderer".Hence the reason why everything breaks down when, god forbid, there is a way that belongs to two classes of networks (say, interstate and U.S. hwy.), because you now have to somehow convey multiple concepts in a single tag (ref). Which is why the operative workaround is to resort to another layer of abstraction (and complexity) in the form of highly-specific relations, when everything could have been taken care of in the first place with directly-applied tags having conceptually-unique keys. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
> > On 10/15/2010 09:44 PM, Richard Welty wrote: > > Sans prefices, the highway=motorway where US Highway 10, Wisconsin Highway > > 66, and Interstate Highway 39 run together would have ref=10;66;39. Not > > very useful for determining which is which. This is why I keep arguing for using *non-ambiguous tag names*: the "what" should go in the tag name, and the "which" should go in the tag value. So, instead of the current situation where we have half a bazillion ways with a "network" tag name, you'd have: network:country[US]:unitedStatesHighway = 10 network:country[US]:state[WI] = 66 network:country[US]:interstate = 39 (Or, if you're of the brevity and ambiguity trumps verbosity and clarity camp, I give you "network:US:WI", "network:US:US", "network:US:I".) Point being, by making a clean separation between the "what" and the "which", it makes it easier from the standpoint of an automated agent of OSM data, be it a renderer or whatnot: you have a clean query on the tag /name/ to get all routes of a certain classification (the "what"), regardless of /which/ route number it is. No endless parsing of the tag value, looking for "I-" to determine whether that way is an interstate, oh, oops, this guy doesn't like hyphens, I need to look for "I*", oh, oops, that gets me everything for Iowa and Idaho, oops, now my function to determine whether a way is an interstate is 1 lines long with 500 "if" statements and regular expressions that would make a CS major run for the hills. No, none of that. Simply: if tag name = "network:country[US]:interstate", render the AASHTO shield with the number(s) in the tag value. Easy peesy. No arguing about relations, super relations, super duper relations, relations of relations of relations of sub-relations, orphan relations, bastard relations, divorced relations, etc. You just tag the ways with these non-ambiguous tag names. Relations are WTFs of complete and utter proportions. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: [OSM-talk] Mapquest launches site based on OSM!
> From: Paul Johnson > Perhaps Richard could shed some more light on this, but relations are > pretty much going to be necessary to properly render route shields given > the huge variety in highway networks in North America and the world. My company has a beta version of a renderer that displays the proper shield, be it interstate, U.S. highway, state, county, or whatnot, without using relations. To do so, it looks for the following tags on a way (i.e., /not/ on its relations): network:country[us]:interstate = 95 network:country[us]:unitedStatesHighway = 1 network:country[us]:state[md] = 99 It also does proper multi-shield rendering of multiplexed routes, be they of the same type... network:country[us]:unitedStatesHighway = 50;301 ...or disparate: network:country[us]:interstate = 70 network:country[us]:unitedStatesHighway = 40 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Rendering of semicolon delimited values (WAS: Would Like To Clean Salt Lake City Street Names)
> From: Kevin Atkinson > If a stretch of road has multiple numbered route, a semi-colon > should be used to separate them and I believe that the render _will_ > recognize those. In my experience, Mapnik renders the semicolon as-is, rather than creating a shield/marker for each individual route number. But don't exceed a certain quantity of characters, because then it won't render a shield at all. The limit is different for the various values of the "highway" tag: it was 6 and 8 characters when I bitched about it some years back: http://trac.openstreetmap.org/ticket/937 Anyway...yet another example of how this practice of cramming every last bit of highway network metadata into the value field of a "ref" tag has its limitations... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: [OSM-talk] Mapquest launches site based on OSM!
From: Nathan Edgars II > There's been no standard way of tagging state highways since before I > joined at the beginning of this year. Nor has there been in my four years here. Hell, I was the one who wrote the wiki suggestion to use the USPS state abbreviations. I am completely and utterly stunned that it is still there. One of my four OSM WTFs is overloading the REF tag's value with so much information. We should be "key rich", not "REF value rich". The *keys* should have the "meat", not the *values*: network:country[us]:state[ks] = 10// renderer sees this and renders a sunburst network:country[us]:state[md] = 26// renderer sees this and renders a white rectangle These tags are simply applied to all of the ways that comprise the route. No complicated relations (the second of my four OSM WTFs) necessary. Need all of the ways for a route? It's a simple database query: SELECT * WHERE key = 'network:country[us]:state[md]' AND value = '26'. If you have a state with different classes of networks, you just extend this idea: network:country[us]:state[va]:primary = 7 // renderer sees this and renders a guitar pick thingie network:country[us]:state[va]:secondary = 606 // renderer sees this and renders a circle If you have a way that is on two networks, you just give it both tags: network:country[us]:unitedStatesHighway = 40 network:country[us]:interstate = 70 Oh, yeah: this also gets rid of those asinine arguments about, say, whether there should be a hyphen in the REF tag between the "I" and the digits in interstate designations. Don't like the hyphen? Knock yourself out, and create a *renderer* that shows "I 95" when it encounters network:country[us]:interstate=95. Prefer hyphens? Or a shield? Whatever. The point is, that's the domain of the *renderer*, not the *metadata*. Moving on, if you have a way that comprises two networks of the same class, you hit OSM's third WTF, which is the inability to have two tags with the same key: network:country[us]:unitedStatesHighway = 50 network:country[us]:unitedStatesHighway = 301 So as a workaround, you have to use the infamous semicolon: network:country[us]:unitedStatesHighway = 50;301 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Gluing boundaries to roads (was Talk-us Digest, Vol 31, Issue 1)
> This is a three minute video on, mostly, maps and addresses. Probably applies > to boundaries too. http://sivers.org/jaddr Interesting. Although, I don't know what it is, but TED speakers always manage to creep me out and sound supremely sanctimonious, no matter how enlightening their subject matter is. Back to OSM: as a traffic engineer, I'll submit that we realign roads all the time, to straighten curves, widen, etc., but, somehow, I don't think the administrative boundaries are changing with them. The OSM concept of having points as first class entities in the data model, rather than just waypoints on polylines, makes it very tempting (and convenient) to "glue" edges of disparate entities. On a small scale, this is handy: that park that fills up a block or cemetery that borders a road renders a lot better if you glue them to the surrounding streets. But add a point to one or the other, and, depending on your editor, it's not guaranteed to be added to both entities. Oops. Also, you have to consider that the current OSM model of modeling only centerlines may change one day (say, tomorrow), to, say, modeling lanes, curbs, or edgelines. Then what...which lane is the administrative boundary? I'd rather not go there. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us