Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Aah, sounds like the cycle_network proponents may have gotten overzealous, then; good catch. Could someone check history and contact mappers? On Mon, Jul 21, 2014 at 6:39 AM, Andy Allan a...@gravitystorm.co.uk wrote: On 20/07/14 18:29, Paul Johnson wrote: On Sun, Jul 20, 2014 at 2:17 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us mailto:m...@nguyen.cincinnati.oh.us wrote: On 2014-07-19 23:29, Paul Johnson wrote: Likewise, I'm in favor of heirarchies similar to road relations for cyclists (ie, Portland area network=lcn becomes US:OR:Multnomah:Portland or US:OR:Metro or US:OR:Multnomah; Tulsa's LCNs would become US:OK:Tulsa:Riverparks or US:OK:INCOG or US:OK:Tulsa or US:OK:Tulsa:Tusla or US:OK:Tulsa:Broken Arrow...etc http://wiki.openstreetmap.org/__wiki/Key:cycle_network http://wiki.openstreetmap.org/wiki/Key:cycle_network http://taginfo.openstreetmap.__org/keys/cycle_network#values http://taginfo.openstreetmap.org/keys/cycle_network#values Nice! OK, so apparently I'm not the first person to think this. Also explains why a vast majority of cycleways, particularly in the areas that taginfo suggests have migrated, aren't rendering on the cyclemap layer. Wonder if we can get Andy Allen to update the style to make use of this scheme. Hi Paul, I think there's some confusion somewhere. As far as I can see the cycle_network and network tags are separate, so you can add these additional tags without removing network=lcn etc. So I don't know what you're asking me to update. Cheers, Andy ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
Hi There are cases where expansion is far from standard, according to local convention. Here in Washington DC, the street names are all suffixed with the quadrant (NW, SE, SW, NE) the road lies in. The official names of the streets kept by the DC city government all use the contraction. Historically, I could find no maps that used the expansion. For spoken navigation systems, this is probably the easiest situation to identify and handle, without ambiguity. OSM maps of DC now just look a bit bizarre. So I don't recommend we apply this expansion without consideration of regional variation. Before any expansion scripts are run, in DC or anywhere, the local community needs to be consulted sufficiently. I think it's also a good idea for DC mappers to reconsider the suffix expansion in our special case. Thanks Mikel ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron mikel.ma...@gmail.com wrote: Here in Washington DC, the street names are all suffixed with the quadrant (NW, SE, SW, NE) the road lies in. The official names of the streets kept by the DC city government all use the contraction. Historically, I could find no maps that used the expansion. The city maps may use the same contractions as TIGER, etc. but we know they're contractions, which is distinct from being words, so I don't the city maps as being a reason for changing the way the entire OSM project handles contractions. BTW, for anyone who isn't aware, I lived in DC from 1996-2012, which is both a long time, and also a recent time. I consider myself essentially a local in this matter. For spoken navigation systems, this is probably the easiest situation to identify and handle, without ambiguity. The real issue is trying to standardize the OSM data for data consumers, which text-to-speech systems will benefit from, but they're not the only ones. OSM maps of DC now just look a bit bizarre. The MapBox folks seemed to have figued this out US-wide and re-contract the road names and the directional identifiers. This is a rendering problem- one which I agree with you 100% that it should be fixed, not just for directions but also for road identifiers, because we in the US are used to seeing contractions. Another proposal I've seen which seemed interesting (though not free of problems) is the idea of a new tag that was basically the name of the road exactly as it appears on a road sign. I agree with you 100% that we should strive for a map that looks American for US map users. The MapBox folks seem to have done it, so really this is a problem with osm.org's map. Their map is really British-Euro centric in many ways, and it would really be nice if we had a good, solid alternative, much like osm.fr. Maybe MapBox can share some of their style with us, or if not, we have our work cut out for us, but I'm sure we can do it. So I don't recommend we apply this expansion without consideration of regional variation. Before any expansion scripts are run, in DC or anywhere, the local community needs to be consulted sufficiently. Can you elaborate on this? - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
On Mon, Jul 21, 2014 at 3:45 PM, Serge Wroclawski emac...@gmail.com wrote: OSM maps of DC now just look a bit bizarre. The MapBox folks seemed to have figued this out US-wide and re-contract the road names and the directional identifiers. Mapbox has an exception for DC that contracts names. While I agree with the paradigm to manage data in a way that is conducive for consuming it, you can use it to construe the argument for _and_ against expansion of DC-like abbreviations (NW, NE, SW, SE quadrants). - If you expand DC-like abbreviations, then you need to contract them when making a map. Now how do you find out systematically which ones are the DC-like abbreviations you need to contract on a global map? - Say you contracted DC-like abbreviations, now you need to somehow find out how to feed them into text to speech. Agreed that DC map looks odd now on OSM. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Tagging cycleways with cycle_network
On Sun, Jul 20, 2014 at 2:17 AM, Minh Nguyen mailto:m...@nguyen.cincinnati.oh.usm...@nguyen.cincinnati.oh.us wrote: http://wiki.openstreetmap.org/wiki/Key:cycle_networkhttp://wiki.openstreetmap.org/wiki/Key:cycle_network http://taginfo.openstreetmap.org/keys/cycle_network#valueshttp://taginfo.openstreetmap.org/keys/cycle_network#values Paul Johnson replied: Nice! OK, so apparently I'm not the first person to think this. Also explains why a vast majority of cycleways, particularly in the areas that taginfo suggests have migrated, aren't rendering on the cyclemap layer. Wonder if we can get Andy Allen to update the style to make use of this scheme. Paul, I don't know what you mean by a vast majority of cycleways...aren't rendering on the cyclemap layer. As long as a route relation is tagged as is documented in numerous places in our wiki, i.e. with a minimum of type=route, route=bicycle, network=[lcn, rcn, ncn] and ref= (1, 2 or 3 alphanumerics), OCM renders it as dark blue, turquoise or red (respectively), and badges it with ref in a rectangular shield. I wouldn't hold your breath that Andy will change OCM to accommodate cycle_network values so these become special shields (a la aperiodic/Mapquest Open); without wishing to put words into his mouth, I feel confident he very likely will not do that in any near-term future. But, laying data groundwork is important. So, I do agree it is a good idea to correctly tag these routes with the data and scheme that Minh points you to (this bicycle-specific syntax mimics Interstate, US and state highway networks), as it may very well get picked up by a renderer style at some point in the future. But in Cycle Map layer, and soon? Likely not. Andy, if you are reading this, I encourage you to chime in with any clarification of your intentions. You may also wish to compare and contrast what Sarah Hoffmann's Lonvia bike route renderer does with OSM bicycle route data: http://cycling.waymarkedtrails.org/en/?zoom=4lat=41lon=-79hill=1#routes . One major difference between the two is that while Andy's Cycle Map layer (OCM) displays proposed routes, Lonvia does not. Also, the Lonvia renderer uses mapnik/Standard as a backdrop: the translucency of this layer can be adjusted with a slider control, as can a hillshading layer, whereas Andy's OCM uses a more customized style without user controls, has fixed elevation/contour lines and displays bicycle-specific amenities (such as bike parking, bike shops, water stations, pubs, toilets, crossings, et cetera). However, neither of these two renderers actually parses cycle_network tags (yet). Maybe, someday, but today, no. I encourage these tags (and yes, taginfo does show them to be both growing in number and becoming more correct) where they are known and able to be correctly entered into OSM. Lay data groundwork! SteveA California___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
I see the reason for all this work is to make the data un-ambigious. To that end expanding all the contractions. This is needed for text to speech, consistent searches, and probably a few other issues. From the expanded data names can be contracted a lot easier without mistakes. Raw data: northwest 15th drive spoken data: northwest fifteenth drive Map data: NW 15th Dr. I don't think we need to store 2 or 3 copies for 99.9% of the names, but some will break the rules the rest follow and need some kind of don't expand flag or alt name(s) stored because of that. Dale Puch On Mon, Jul 21, 2014 at 9:45 AM, Serge Wroclawski emac...@gmail.com wrote: On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron mikel.ma...@gmail.com wrote: Here in Washington DC, the street names are all suffixed with the quadrant (NW, SE, SW, NE) the road lies in. The official names of the streets kept by the DC city government all use the contraction. Historically, I could find no maps that used the expansion. The city maps may use the same contractions as TIGER, etc. but we know they're contractions, which is distinct from being words, so I don't the city maps as being a reason for changing the way the entire OSM project handles contractions. BTW, for anyone who isn't aware, I lived in DC from 1996-2012, which is both a long time, and also a recent time. I consider myself essentially a local in this matter. For spoken navigation systems, this is probably the easiest situation to identify and handle, without ambiguity. The real issue is trying to standardize the OSM data for data consumers, which text-to-speech systems will benefit from, but they're not the only ones. OSM maps of DC now just look a bit bizarre. The MapBox folks seemed to have figued this out US-wide and re-contract the road names and the directional identifiers. This is a rendering problem- one which I agree with you 100% that it should be fixed, not just for directions but also for road identifiers, because we in the US are used to seeing contractions. Another proposal I've seen which seemed interesting (though not free of problems) is the idea of a new tag that was basically the name of the road exactly as it appears on a road sign. I agree with you 100% that we should strive for a map that looks American for US map users. The MapBox folks seem to have done it, so really this is a problem with osm.org's map. Their map is really British-Euro centric in many ways, and it would really be nice if we had a good, solid alternative, much like osm.fr. Maybe MapBox can share some of their style with us, or if not, we have our work cut out for us, but I'm sure we can do it. So I don't recommend we apply this expansion without consideration of regional variation. Before any expansion scripts are run, in DC or anywhere, the local community needs to be consulted sufficiently. Can you elaborate on this? - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
