Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
Concerning ref tags on ways, I don't think there's a need to impose nationwide consistency. I also don't think it's worth even adhering to a strict machine-parseable syntax (particularly dealing with overlaps) since that kind of information is much better organized in relations. That said, here are my ideal guidelines for formatting ref tags on single state highways: 1) If there is one clearly-popular abbreviation, such as M-xx in Michigan or possibly K-xx in Kansas, use it. 2) If a state has primary and secondary state routes, or numerous classes of state routes like Texas, the prefix should indicate the route class. 3) If a state allows its state routes to have the same number as a US or Interstate route in that state, a state-specific prefix (postal abbreviation or other as described above) should be used. 4) If a state is large (such that most places aren't near the borders) a generic prefix like SR or SH or STH (depending on preferred local terminology) may be used, notwithstanding guideline 3. 5) If a state's state route markers are generic (circle/oval or box) and don't specifically identify the state, a generic prefix or no prefix may be used, notwithstanding guideline 3. 6) Consistency within a state, or within broad regions of larger states, is probably still of value. A format should be chosen by consensus of mappers familiar with the state or region in question. 6a) As a mapper familiar with Ohio, I prefer SR xx, but would be amenable to OH xx or OH-xx. Slightly off-topic: A) I strongly prefer I-xx and not I xx (and definitely not Ixx) for Interstates. The hyphen enhances readability and reduces the chance of the I being mistaken for a 1. The reasons I've heard in support of I xx are: to match US and state routes (why does it have to?); to match European route designations (making apples look like oranges); because all the Interstates are already tagged as I xx (due to a few editors who value consistency a little too highly, plus I see that as a circular argument); changing it breaks renderers (nearly all renderers just pass a way's ref tag directly to the output, and those that do try to parse it can and should normalize tagging variations as a preprocessing step anyway). On the other hand, I would't argue against the format IH xx in Texas because most Texans I've encountered write it that way. B) When routes overlap, there is no right way to format the way's ref tag. I don't think any active renderers attempt to separate it into multiple values; considering this information can be stored with much better structure in relations, I don't think any programmer wants to bother with trying to parse a ref string anyway. That just leaves humans who will ever read it, and we can optimize for that. Brevity may be more important than technical correctness when a human is reading. Local understanding of routes' relative importance may play a role. The following equations demonstrate options to represent overlapping routes in a way's ref tag that seem perfectly sensible to me: US 1 + US 9 = US 1-9 I-70 + I-71 = I-70/71 US 40 + US 62 + OH 16 = US 40-62 I-74 + I-465 + (?) = I-465 I-95 + MA 128 = I-95/128 US 68 + OH 15 = OH 15 These little white lies are close enough to match the line on the map to the road on the planet. (Every good map has to lie in some way to convey information effectively.) If someone really wants to know which routes follow a particular way, they should examine the relation(s) that contain it. If a mapper really wants to make sure the correct, official truth is represented in the database, they should make sure all relevant route relations exist and are correct. Trying to squeeze all that information into a single string with a rigid syntax is optimizing for a use case that essentially doesn't exist. On Sep 12, 2012 8:59 PM, Charlotte Wolter techl...@techlady.com wrote: Hello all, ****Was there ever consensus on whether to use SR (or some variation on that) for state highways versus an abbreviation of the state name (CA or NY). I remember that there was discussion, but I don't remember if there was consensus. ****Thanks. Charlotte ** ** Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady *The Four Internet Freedoms* Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
On 9/12/2012 11:19 PM, Richard Welty wrote: what i recall is that NE2 likes the appearance of bare route numbers and most of his ref tags have no prefix at all (see FL, PA, NJ among other states where he did a lot of this.) I've seen a number of people who put the bare number in the ref tag for state (and county?) routes. I don't understand that either. The good news is that once the Shields rendering implementation comes to the US, is that relations will be the order of the day and unambiguous. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Highway shield rendering: What's the blocker?
if I remember correctly, the US Local Chapter was planning to render highway shields, now that combined shield and overlap rendering is solved. What happened to that? Is there a blocker? If so, what is / are the blocker(s)? There appears to be periodic community interest in highway shields. Who is still interested in advancing this? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway shield rendering: What's the blocker?
On Thu, Sep 13, 2012 at 7:58 AM, Richard Weait rich...@weait.com wrote: if I remember correctly, the US Local Chapter was planning to render highway shields, now that combined shield and overlap rendering is solved. What happened to that? Is there a blocker? If so, what is / are the blocker(s)? There appears to be periodic community interest in highway shields. Who is still interested in advancing this? I committed to throwing together the render after an ODbL licensed planet was released so I could reimport and not have to worry about dropping/re-adding the database. Sounds like just such a planet is available, so I will try to get that imported as soon as possible. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway shield rendering: What's the blocker?
Hi, On 09/13/2012 03:12 PM, Ian Dees wrote: Sounds like just such a planet is available, ... in a couple hours! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
David, I agree with much of what you said. However, I'm not sure why the size of a state should make a difference in what abbreviation is used. Large or small, shouldn't the state abbreviation be consistent? Also, in the B section, where you suggest US 1 plus US 9 could be abbreviated as US 1-9, I think that could be misleading. It is common to use a hyphen between numbers, such as 1-9, to signify 1 through 9. That's not what you meant. And the use of a slash would seem OK if the prefix always is there, the I or whatever state prefix applies. For example I 70/I 71 or I 95/MA 128. Otherwise, I think, there is potential for confusion. At any rate, I hope we can come to some kind of agreement on what to do about overlapping routes. Now we use semicolons to separate overlaping routes, but Potlatch 2 always flags those as incorrect. I corrected a bunch of those before someone told me that it's just a problem in Potlatch 2. So, it would be great if there were some clarity on that. Anyone? And, bring back the hyphen in interstate highway refs! Here's to I-10, which really does need a hyphen. So from now on I'll use state abbreviations and do relations, relations, relations. Charlotte At 11:57 PM 9/12/2012, you wrote: Concerning ref tags on ways, I don't think there's a need to impose nationwide consistency. I also don't think it's worth even adhering to a strict machine-parseable syntax (particularly dealing with overlaps) since that kind of information is much better organized in relations. That said, here are my ideal guidelines for formatting ref tags on single state highways: 1) If there is one clearly-popular abbreviation, such as M-xx in Michigan or possibly K-xx in Kansas, use it. 2) If a state has primary and secondary state routes, or numerous classes of state routes like Texas, the prefix should indicate the route class. 3) If a state allows its state routes to have the same number as a US or Interstate route in that state, a state-specific prefix (postal abbreviation or other as described above) should be used. 4) If a state is large (such that most places aren't near the borders) a generic prefix like SR or SH or STH (depending on preferred local terminology) may be used, notwithstanding guideline 3. 5) If a state's state route markers are generic (circle/oval or box) and don't specifically identify the state, a generic prefix or no prefix may be used, notwithstanding guideline 3. 6) Consistency within a state, or within broad regions of larger states, is probably still of value. A format should be chosen by consensus of mappers familiar with the state or region in question. 6a) As a mapper familiar with Ohio, I prefer SR xx, but would be amenable to OH xx or OH-xx. Slightly off-topic: A) I strongly prefer I-xx and not I xx (and definitely not Ixx) for Interstates. The hyphen enhances readability and reduces the chance of the I being mistaken for a 1. The reasons I've heard in support of I xx are: to match US and state routes (why does it have to?); to match European route designations (making apples look like oranges); because all the Interstates are already tagged as I xx (due to a few editors who value consistency a little too highly, plus I see that as a circular argument); changing it breaks renderers (nearly all renderers just pass a way's ref tag directly to the output, and those that do try to parse it can and should normalize tagging variations as a preprocessing step anyway). On the other hand, I would't argue against the format IH xx in Texas because most Texans I've encountered write it that way. B) When routes overlap, there is no right way to format the way's ref tag. I don't think any active renderers attempt to separate it into multiple values; considering this information can be stored with much better structure in relations, I don't think any programmer wants to bother with trying to parse a ref string anyway. That just leaves humans who will ever read it, and we can optimize for that. Brevity may be more important than technical correctness when a human is reading. Local understanding of routes' relative importance may play a role. The following equations demonstrate options to represent overlapping routes in a way's ref tag that seem perfectly sensible to me: US 1 + US 9 = US 1-9 I-70 + I-71 = I-70/71 US 40 + US 62 + OH 16 = US 40-62 I-74 + I-465 + (?) = I-465 I-95 + MA 128 = I-95/128 US 68 + OH 15 = OH 15 These little white lies are close enough to match the line on the map to the road on the planet. (Every good map has to lie in some way to convey information effectively.) If someone really wants to know which routes follow a particular way, they should examine the relation(s) that contain it. If a mapper really wants to make sure the correct, official truth is represented in the database,
Re: [Talk-us] Highway shield rendering: What's the blocker?
can't wait! Unfortunately, I don't have enough disk space to import a ODbL planet while keeping the CC planet up. I need an up-to-date ways table to run the Fairy Dust against for the Remap-a-tron. Or more to the point: I need a current osmosis snapshot schema ways table (with ways geometry) and my custom deletedways table plus my Fairy Dust PL/PGSQL function in one database, and a cron job to run the Fairy Dust periodically, and either hosting of a simple python web service that extracts a random un-remapped way as geojson or access to the deletedways table for that script running remotely. Who can help out with that? Martijn On Thu, Sep 13, 2012 at 8:21 AM, Frederik Ramm frede...@remote.org wrote: Hi, On 09/13/2012 03:12 PM, Ian Dees wrote: Sounds like just such a planet is available, ... in a couple hours! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
On Thu, Sep 13, 2012 at 1:57 AM, David ``Smith'' vidthe...@gmail.com wrote: Concerning ref tags on ways, I don't think there's a need to impose nationwide consistency. I also don't think it's worth even adhering to a strict machine-parseable syntax (particularly dealing with overlaps) since that kind of information is much better organized in relations. Agreed but virtually no common tools actually use route relations yet. According to another message on this mailing list today we will finally get a rendering with shields based on relations up soon. So hopefully this is the beginning of a wider adoption of route relations. That said, here are my ideal guidelines for formatting ref tags on single state highways: 1) If there is one clearly-popular abbreviation, such as M-xx in Michigan or possibly K-xx in Kansas, use it. Most of the ones in Kansas are actually KS XX - might have something to do with me having done most of them and I consider national consistency to be of value :) B) When routes overlap, there is no right way to format the way's ref tag. I don't think any active renderers attempt to separate it into multiple values; considering this information can be stored with much better structure in relations, I don't think any programmer wants to bother with trying to parse a ref string anyway. That just leaves humans who will ever read it, and we can optimize for that. Actually, Mapquest does parse the ref tags to some degree. They strip out prefixes and only show numbers for state highways. I'm pretty sure they used to only strip out postal abbreviations but it looks like they've expanded the algorithm a bit to include other common values. They also parse out multiple values (possibly just up to two?) as seen here on both I-70/US40 and I-135/US81 although the US81 isn't rendered as a US highway shield for some reason like it is north of Salina where it no longer overlaps I-135: http://mapq.st/Pw6u5J Toby On Sep 12, 2012 8:59 PM, Charlotte Wolter techl...@techlady.com wrote: Hello all, Was there ever consensus on whether to use SR (or some variation on that) for state highways versus an abbreviation of the state name (CA or NY). I remember that there was discussion, but I don't remember if there was consensus. Thanks. Charlotte Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
On 9/13/2012 1:15 PM, Toby Murray wrote: Most of the ones in Kansas are actually KS XX - might have something to do with me having done most of them and I consider national consistency to be of value I would agree with national consistency. There will always be contention - in SC, the DOT refers to state and county roads with an internal numbering system as SR-*-*; some of those appear on signs. But to the average motorist - all state routes are referred to as SC_* I wouldn't have a clue about how to ref the Texas Farm* roads ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
On Sep 13, 2012 11:51 AM, Charlotte Wolter techl...@techlady.com wrote: David, I agree with much of what you said. However, I'm not sure why the size of a state should make a difference in what abbreviation is used. Large or small, shouldn't the state abbreviation be consistent? In most parts of a big state, one is surrounded by that state and no others, so state route is unambiguous. In a small state with many neighbors, there are always other states nearby, so disambiguation may be called for. Anyway, this particular guideline wasn't meant to carry a lot of weight. Also, in the B section, where you suggest US 1 plus US 9 could be abbreviated as US 1-9, I think that could be misleading. It is common to use a hyphen between numbers, such as 1-9, to signify 1 through 9. That's not what you meant. I've seen photos of single US route markers that literally say 1-9 in the interior. I have also seen people refer to combined US routes in this way. And to split hairs, a range of numbers should be written with an en dash, not a hyphen. And the use of a slash would seem OK if the prefix always is there, the I or whatever state prefix applies. For example I 70/I 71 or I 95/MA 128. Otherwise, I think, there is potential for confusion. Confusion because someone might read Interstate 128 when it's a state route? I'm sure that mistake is not new, and it still doesn't really interfere with a human matching the map to reality. I value brevity when writing refs for human consumption. In the context of agging ways, I assume the ref value is displayed unmodified to a human (if at all), so I choose to optimize for humans. At any rate, I hope we can come to some kind of agreement on what to do about overlapping routes. Now we use semicolons to separate overlaping routes, but Potlatch 2 always flags those as incorrect. I corrected a bunch of those before someone told me that it's just a problem in Potlatch 2. So, it would be great if there were some clarity on that. Anyone? The semicolon method is, in my opinion, just as valid for overlaps as the examples I provided; it's just not optimized for humans. Potlatch doesn't actually flag it as an error, but it thinks it might need to be checked (as if two different values were combined when ways were joined, and maybe only one value should apply). I think it just needs to be tweaked so mappers interpret it as a warning that can be OK as-is, and not an outright error. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Canada and US Imagery bounds
I've gone and updated the imagery bounds and bboxes for both Potlatch 2 and JOSM for the North American imagery sources. JOSM should now only suggest a source if it actually covers the area. Potlatch 2 will still suggest sources even if they don't cover the area because potlatch 2 only supports bboxes, not polygons and the bbox for most of the US sources looks like http://www.openstreetmap.org/?box=yesbbox=-124.819%2C24.496%2C-66.930%2C49. 443 I have also set up bc_mosaic, a source covering Greater Vancouver, Fraser Valley, and the Sea 2 Sky corrider up to Pemberton. Both JOSM and PL2 should suggest it. The source is the various sources listed on http://imagery.paulnorman.ca/tiles/about.html combined into one layer. The individual layers will be faster but not as convenient. To update the layer information in JOSM use the reload button to the right of the map on the Imagery Preferences tab of Preferences. You may of course find that if you live right on the border that some suggestions are not ideal but the error is now measured in hundreds of meters, not hundreds of kilometers. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
