Re: [Talk-us] NYC Name Vandalism
> In any case all of the above potentially lead to your private fork of the > planet getting out of sync real fast with the original, implying that > applying diffs will become > more problematic over time. So you wouldn't be able to take you fixed and > known good planet fork, apply only good diffs, and expect to be able to > continue to do that > for a year or so. No, that's not the idea at all. It's to download planet files regular, identify problematic recent changes, revert only those. You still need a history to revert. Contribute back to the OSM community what the problematic attributes/object are, and a human can revert them. > IMHO the only thing that could really work in the OSM model is reverting real > fast in the -original- dataset. Fixing the original dataset *is* paramount. However, it's important to understand that there's this transitional problem; that, any given version of the dataset will have defects, and to catch the most egregious of these - particularly from vandalism is really the only goal here. Not every use of OSM data will be pulled with high frequency from the database; there are offline applications where it's "pull once, use for a few years". You may be able to rely on the community to repair persistent high-profile issues, but these transitory issues are another matter. > Naturally there is the other aspect that we want our contributors to gain > experience and become better mappers over time. You are only going to get > that if leave the > opportunity to make mistakes open and don't robo-fix > everything that goes wrong It's not robo-fixing, it's "robo-flagging for moderation". Fundamentally different thing. Something that has be vetted could certainly violate any rules this flagging uses. -Alan ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NYC Name Vandalism
Hi, Perhaps I didn't express it clearly, but my interest was in the idea that certain. rather limited changelists could be flagged for moderation before they are put into main dataset. There will always be things that seem like they should be blocked, but are actually appropriate. In the interest of having the most accurate data, I'm not convinced this form of moderation can't have a role. As I understand it, the virtue of OSM is to allow anyone to contribute accurate, detailed local knowledge about the places they know about; however, there's no value in having junk in the database for even a moment, if it can be avoided. Place names are usually verifiable facts, even disputed place names. So you don't want the open nature of OSM to compromise accuracy, or a quest for accuracy to discourage people from contributing accurate information. I said my peace; I suspect the OSM community is not culturally disposed to that form of moderation. So I will ask about a different approach. In my case, I've seen editing errors that affected motorway connectivity (not vandalism), that were made and corrected within a couple hours. Pretty good - except our planet file was in that two hour window. I want to avoid these errors, without getting caught in the errors of the next two hour window. I'm not sure if Mapbox or others use a process like this, but this is what I can imagine: PLANETcur is the current planet filePLANETprev is the last used planet fileCHANGEcur-prev is a comprehensive list of changelists between the two datasets A particular consumer of OSM data can automatically scan CHANGEcur-prev and/or PLANETcur for potentially troubling content, according to their own criteria. In their local copy, if they detect something they do not want to accept - offensive place names, incomplete topology - they can attempt to revert - in their local copy only! - recent changes that violate their criteria. They accept whatever mistakes their "reversion" algorithm makes. The identified "questionable changelists" can be submitted back to the OSM community to review and revert, but always by a human. My hope is that I am being completely unoriginal, and I can cobble together existing tools quickly. How unoriginal am I? I am looking over the osmcha.mapbox.com page, and saw reference to a utility called "osm-compare": https://github.com/mapbox/osm-compare/blob/master/comparators/README.md - which has an obscenity filter. If I understand this correctly, osm-compare flags changelists for review, osmcha.mapbox.com allows people to review the flagged datasets and reverse bad edits. Could someone define osm-compare filters that produce results that can be automatically pulled into a local copy? (If a changeset has been reviewed by a second person - can that information be provided). All I want is something that allows me to be a little bit more conservative in accepting edits, without requiring complex processes or large resource. A little insight would be appreciated. Thanks,Alan On Wednesday, September 5, 2018, 7:52:46 AM PDT, Simon Poole wrote: osmcha (osmcha.mapbox.com) already does most of this. While detecting vandalism in general is difficult, edits like those in question are easy to detect and small in number. IMHO it really isn't an issue with openstreetmap in this case, as even with the delay (somebody reported the user in question instead of reverting and then reporting) in the specific case the vandalism was swiftly removed. The reason that this is being discussed at all is because of the edit resurfacing with a third party and having to be a) detected, b) reported, and c) fixed again. Yes what we know this was a glitch in the third parties workflow, but they are bound to happen and we shouldn't pretend given the large number of edits that any procedures put in place are going to be 100% effective, be it directly with OSM or by third parties. Simon Am 05.09.2018 um 16:23 schrieb Greg Troxel: > I tend to agree that automated systems are going to be not that useful. > > I tend to notice some things in my area, but it's hard to keep track. > > This makes me wonder about a tool that > > - lets people sign up to watch edits, in some area, or in general, > sort of like maproulette. Use some scoring system where new > mappers edits are more likely to be looked at by somebody, and > people who claim an area as theirs are more likely to get shown > edits there, or maybe let people get all edits in some bbox > > - lets people give a rating to a changeset, something like: > i) high priority for inspection by others > ii) worthy of being checked by a local > iii) probably ok > iv) definitely ok > > - presents things to multiple people > > - somehow uses a rater's own edit history to validate this (perhaps be > cautious about people with < 500 changesets, and very cautious < 50) > > > This is a slippery slope
Re: [Talk-us] NYC Name Vandalism
Hi - I haven't commented on this forum for several years, but this event did catch my attention. There are some uses of OSM map data which would not allow for frequent updates - offline uses - and therefore, a way of catching such vandalism immediately - less than a day, even - would be very helpful. The thought that occurred, is that certain attributes of certain high profile objects should be caught - or even stopped - very early. The name tag of New York City should be an obvious example - what would cause it to change (short of us selling it back to the Dutch, or similar event)? A new user, offensive language (one of the new street names in the changelist had the word "fuck", and "Adolf Hilter") - these should be immediate red flags. In principle, changelists could be submitted to some sort criteria that could trigg moderation, instead of automatically checking it in. Granted, it would be nearly impossible to make this criteria perfect: there's not offensive about the word "Jew", but it was applied in an offensive way in this situation; I'd have no idea what would be offensive in Hungarian, much less Thai; someone could draw something offensive (like a peeing Android) that would be very hard to catch; there are places like "Dildo, Newfoundland" that are legitimate. But I don't think it would be all that hard to flag a changelist like this last vandalism, without interrupting legitimate edits by very much. At very least, you can force your vandals to be clever to succeed. In our usage, we will scan the names of significant objects for potentially offensive changes. But it would be good to have some sort of gateway in the OSM database itself. I don't understand any of the details of the OSM check-in process, if there is any monitoring for potential vandalism. -Alan ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] converting .osm to a particular shapefile schema
Thanks for the responses to these questions ... I'll have to carefully consider each response. I' By pre-existing schema - I mean the something that looks like the shapefile formats of one of the major commercial map data providers. We have tools that can consume those formats - and my hope was that it would be easier to write a tool that could get the data to conform to one of those schemas, than it would be to consume the format directly. You cannot prevent the birds of sorrow from flying over your head, but you can prevent them from building nests in your hair.” - Chinese Proverb From: Frederik Ramm frede...@remote.org To: Alex Barth a...@mapbox.com Cc: OpenStreetMap talk-us list talk-us@openstreetmap.org Sent: Thursday, July 25, 2013 1:34 PM Subject: Re: [Talk-us] converting .osm to a particular shapefile schema Hi, On 25.07.2013 18:24, Alex Barth wrote: On Thu, Jul 25, 2013 at 9:25 AM, Frederik Ramm frede...@remote.org mailto:frede...@remote.org wrote: With osmosis there comes a little utility called osmjs You mean Osmium, right? With osmosis there comes a little utility called osmjs Yes, my bad. Too many OSMiliar names ;) 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___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] converting .osm to a particular shapefile schema
Hi - I have a question about exporting OSM data. Pardon me if this is the wrong group; please direct me to the correct one if it is. I'd like to see if I can take .osm format data, and rearrange it - to the extent possible - to shapefiles using a pre-existing schema. What is the easiest way to do this? I know I can always use xml parsers and shapefile libraries, but if can get my desired result with config files and existing programs - or, most of the way to my desired result - this will save a lot of time. I've seen some already shapefiles at geofabrik.de, but it's in a different schema than I'd like, and they drop information that I'm interested in. For instance, I'd like to convert tags highway=primary and highway=secondary into numeric functional road class values 1 and 2, respectively. I saw a tool called osm2shp, but I don't know if it's possible to fully control the schema of the output. Anyone have experience with this, or have an idea how to do this? I may just write an XML parser to take in the .osm file directly, but I'd appreciate any help with making this project as simple as possible. Thanks! -Alan You cannot prevent the birds of sorrow from flying over your head, but you can prevent them from building nests in your hair.” - Chinese Proverb___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of highway=tertiary
In an urban area, I think of tertiary as being the road you use to go between and through neighborhoods. I also aim for a particular aesthetic: Between every pair of primary roads, there usually will be one or two secondary roads. Between every pair of secondary roads, there usually will be one or two tertiary roads. Of course - it doesn't always work out this way. In a given area, all secondary roads should have roughly the equivalent capacity and significance, and all tertiary roads should have roughly the equivalent capacity and significance. But following this aesthetic makes a map attractive and useful to the reader. From: Greg Troxel g...@ir.bbn.com To: Matthias Julius li...@julius-net.net Cc: talk-us@openstreetmap.org Sent: Tue, January 5, 2010 7:37:16 AM Subject: Re: [Talk-us] Use of highway=tertiary Matthias Julius li...@julius-net.net writes: Greg Troxel g...@ir.bbn.com writes: Stellan Lagerstrom lagerst...@blindsight.com writes: We have a user (mk408) who seems intent on turning 3/4 of all residential streets in the bay area into tertiary. This seems excessive to me. Most of these are just residential streets, not thoroughfares, etc. Views? Here's one changeset: http://www.openstreetmap.org/browse/changeset/3519089 I think tertiary is way overused. Starting with the notion that highway=secondary should be a state highway, tertiary should be a significant road that people use to get to a state highway, or at least a link between population centers of thousands of people. Other main roads within a city would then be unclassified. Not every secondary highway needs to be a state highway. I would tag roads that have more than just local relevance as tertiary. Sure, I do too. But for me to call something secondary, it has to have the same level of importance to users as a state highwway. more than just local relevance makes sense for tertiary to me. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] city polygons too large for potlatch to handle?
Hi - This might not be the right group to direct this technical question - but I'll put it out there anyhow. I noticed a little while ago that city polygons where added to the OSM database (at least in the SF Bay Area) - and that's a good thing. There is a city boundary that runs along a major road between San Jose and Campbell that I meant to clean up, by getting it to run along the median of the street. I was also going to redigitize this road as the dual carriageway that it is. Here's a junction between Bascom Ave, California Highway 85, and some of the city polygon boundaries: http://www.openstreetmap.com/?lat=37.254578lon=-121.951574zoom=18layers=B000FTF Every time I try to edit (or even select) the city polygon - to delete unnecesary points, or to get it to run nicely up the middle of the road - potlatch gets stuck in a loop. It eventually shows me a warning: A script in this movie is causing Adobe Flash Player 10 to run slowly. If it continues to run, your computer may become unresponsive. Do you wish to abort the script? After which, it's impossible to complete the edit. This problem is making it difficult to clean up this street. Are the developers aware of this problem? Is there anything that can be done? I was hoping that the new version of Potlatch would correct the problem, but it's not the case. -Alan___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] city polygons too large for potlatch to handle?
Rather than blowing it away, perhaps there should be a tool to automatically cut and replace large polygons with multiple smaller polygons? Perhaps someone could write a routine using GPC: http://www.cs.man.ac.uk/~toby/alan/software/ . Years ago, when I worked at Etak, the internal format (mapengine) had a limit of 255 points per polygon; all software interfacing with it had to maintain this limit. The limit doesn't have to be that low, but perhaps it should be low enough for Potlatch to handle anything. Of course, the downside is that you can't assume that a polygon's border will the border of the administrative unit or physical feature represented. (How is this handled for Oceans?) The boundary polylines and polygons have to be distinct. -Alan From: Chris Lawrence lordsu...@gmail.com To: OpenStreetMap U.S. talk-us@openstreetmap.org Sent: Tuesday, April 28, 2009 12:17:58 AM Subject: Re: [Talk-us] city polygons too large for potlatch to handle? On Tue, Apr 28, 2009 at 2:02 AM, Alan Brown adbrown1...@yahoo.com wrote: This might not be the right group to direct this technical question - but I'll put it out there anyhow. I noticed a little while ago that city polygons where added to the OSM database (at least in the SF Bay Area) - and that's a good thing. There is a city boundary that runs along a major road between San Jose and Campbell that I meant to clean up, by getting it to run along the median of the street. I was also going to redigitize this road as the dual carriageway that it is. Here's a junction between Bascom Ave, California Highway 85, and some of the city polygon boundaries: http://www.openstreetmap.com/?lat=37.254578lon=-121.951574zoom=18layers=B000FTF Every time I try to edit (or even select) the city polygon - to delete unnecesary points, or to get it to run nicely up the middle of the road - potlatch gets stuck in a loop. It eventually shows me a warning: A script in this movie is causing Adobe Flash Player 10 to run slowly. If it continues to run, your computer may become unresponsive. Do you wish to abort the script? After which, it's impossible to complete the edit. This problem is making it difficult to clean up this street. Are the developers aware of this problem? Is there anything that can be done? I was hoping that the new version of Potlatch would correct the problem, but it's not the case. Ick. It's possible the OSM API 0.6 upgrade brought in polygons ways that are now too big to edit because they're over the 0.6 limit of 2000 nodes per way--it is not at all clear what the migration for existing polygons/ways was. You may need to use JOSM to do at least a basic edit on these polygons then upload and continue work in Potlatch. (Alternative theory: Potlatch has also just been generally flaky for me post-upgrade, so it could just be Potlatch-flakiness.) Worst comes to worst I can try to blow away the California upload and upload a 0.6-friendly version. I have a very nice, mostly-way-based conversion setup respecting the 0.6 API limits and using complex multipolygon relations that I implemented starting with the Idaho (complete) and Illinois (uploading now) boundaries; ideally I'd like to go back and redo the boundaries in the A-H states if I can think of a sensible way to do it. (Texas I will have to blow away and redo anyway, which I'm not looking forward to.) Chris ___ 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] Public Domain Non-GPS Data Question
This is still treacherous ground. Say you compared Yahoo and Microsoft - and they had the same name. It doesn't matter - the real owner of the copyright to that data is Navteq; it's still a single source, and you could still be caught by copy traps. It's always better to rely on sources without copyright ambiguities.From: Hilton Long seldom.s...@verizon.netTo: talk-us@openstreetmap.orgSent: Friday, February 27, 2009 3:14:18 AMSubject: Re: [Talk-us] Public Domain Non-GPS Data Question This discussion about facts versus “creative spark” relates to a question I raised earlier about street names, which may only be available on commercial databases like Google, Yahoo, and Microsoft “Live Earth”. I propose that when Google and Yahoo agree that the name of the street is “Main Street”, it is a fact, and no longer possesses that “creative spark” that might exist if somebody creating an easter egg spelled it “Maine Street”. The counties or municipalities may not have the data in a convenient form, and street signs may not exist. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [Talk-us-bayarea] Backcountry weekend
Oh, I thought they had to discontinue this for lack of state funds ... I've gone on this event twice - not for the purpose of mapping, but it's a good way to see some wilderness surprisingly close to the Bay Area. A fair bit of this area got burned by the massive 50,000 acre fire 1 1/2 years ago ... however, fire is a normal part of the life cycle here. If the rains finally pick up this winter, it might be great for wildflowers. In 1998, when I went after El Nino, this area had the more amazing wildflowers I had ever seen. From the mapping perspective - it's more a fun project than a practical one. Besides this weekend, only a few of the hardiest backpackers make it into this region each year. They have a few very small but very interesting archaelogical sites and geological sites. Some of the archaelogical sites (Indian ruins) they intentionally keep secret to protect. I volunteered with this park for a couple years .. that was a decade ago. They have a robust volunteer organization, and they might have a practical use for some information to be mapped out. Thanks for the info - I'll look into it. Alan From: Sarah Manley sa...@cloudmade.com To: Talk-us@openstreetmap.org Sent: Friday, February 20, 2009 10:04:19 AM Subject: [Talk-us] Fwd: [Talk-us-bayarea] Backcountry weekend Any bay area folks interested in this? Begin forwarded message: From: Nathan Mixter srmix...@hotmail.com Date: February 19, 2009 1:09:07 PM PST To: talk-us-baya...@openstreetmap.org Subject: [Talk-us-bayarea] Backcountry weekend Reply-To: srmix...@hotmail.com Henry Coe Park south of San Jose in Santa Clara County will be holding its annual backcountry weekend April 24-26. They will be opening the backcountry for people to drive in. It is a great opportunity to map some of the areas that usually take a day or more to get to on foot. Maybe we could get a mapping party or something going. The park is currently taking applications. It usually fills up fast, so get your applications in early. Details, http://www.coepark.org/orestimba.html. ___ Talk-us-bayarea mailing list talk-us-baya...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us-bayarea Sarah Manley sa...@cloudmade.com Cell: 631-338-3815 Skype: Sarah_cloudmade Twitter: SarahManley___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Highway Classification (Was: directions of ways in MassGIS data)
There was a discussion on this list ("Road classification") a short while ago about the "Highway" tag that should be revisited. Someone posted a classification system back in December that made a lot of sense, and is more in sync with what I know commercial data providers. Basically, it would be treating the "highway" tag as providing a functional road classification, rather than (primarily) a legal classification or a physical description. In a nutshell, "Primary" = Road to take you between cities, "Secondary" = Road to take you across cities, "Tertiary" = Road to take you through neighborhoods. It ends up roughly correlating with physical or legal designations - but not exactly. It's marking the relative importance of a particular road. (Motorways and Trunk Roads are
exceptions to this, as they do have specific physical descriptions.) Because of this, I quite disagree with the statement that the tag should be used as a general description of the physical attributes of a road; there are physical description tags to serve that purpose. There are many cases where a two lane highway is by far the most important road in a region (Transcanadian Highway, US 50 in Nevada), while in urban areas like San Jose, you have relatively unimportant roads with two or three lanes in each direction for short distances. Yes, there is definitely subjective judgement here, but it's the sort of subjective cartographers make on a regular basis, and it is very useful. You want a good balance between primary, secondary, and tertiary roads. -AlanHere is map...@att.net's old post:In OSM language the Highway feature is used to designate what we call roads.
A motorway is a four+ lane, limited access, grade separated freeway. These can include Interstates, US Highways, State Highways, County Highways
or even Farm to Market Roads if they meet certain criteria. These
criteria are limited access,the use entrance/exit ramps to access the
freeway. Intersections with other roads are at grade seperated
crossings or ramps. A grade separated crossing means one road goes over
or under the other. (ie. over/underpass) When Motorways meet other
motorways they generally use ramps that are classified as Motorway
Link. These motorways usually connect to other cities or move the
traffic around and through a city. Limited access ring roads usually
fall in this feature class also.
A trunk is what a motorway becomes when it loses one of it's
criteria. This usually occurs to US, State, County highways as they
move outside the urban areas. Intersections with other roads can occur
at grade and/or when ramps are no longer needed to access the road.
Usually they remain 4+ lanes and may or may not be divided by a
physical median.
A primary road can be a US, State, County Highway or other road
that connects two cities or moves traffic from one part of the city to
the other. These are the highways that become Main St when they go
through a small rural town. They will have traffic signals
when they reach more densely populated areas. These are the roads you
jump on when the freeway has an accident and you don't want to sit and
wait it out.
A secondary road moves traffic within a city. It would service only a certain area within a city.
A tertiary road connects the residential roads to the higher classes: motorway, trunk, primary or secondary.
I hope this clarifys things for some users. I know it's not going to please those who have already used other classification schemes.
thanks,
pete
From: David Lynch djly...@gmail.comTo: Talk-us talk-us@openstreetmap.orgSent: Tuesday, February 3, 2009 8:49:26 AMSubject: Re: [Talk-us] US Highway Classification (Was: directions of ways in MassGIS data)
What I've tended to do in my part of Texas is:Motorway - two or more consecutive intersections with grade separation and no driveways, or any interstate (some very rural locations do have the occasional turn off directly from the main travel lanes)
Trunk - US highways without any other reason to classify them up or down and high speed divided roads with relatively few crossings and an occasional grade separationPrimary - State highways, US highways running near and parallel to a motorway, and wide, heavily-traveled urban/suburban streets
Secondary - Other state highways (farm-to-market roads, loops, spurs) and major city streetsTertiary - Residential collector streets, some rural roads that are in good condition and connect to classified highways, and service roads running parallel to a motorway.
On Tue, Feb 3, 2009 at 09:44, Zeke Farwell ezeki...@gmail.com wrote:
We need a detailed road classification chart on the US wiki page to straighten all of this out ! Maybe I'll find the time to get working on that one of these days... I think I'm also having trouble making the OSM road classification system do everything I want it to.
"the consensus is that the highway tag is for making a general description of the physical attributes of a highway. This gives the user
Re: [Talk-us] County Line Corrections
I know of some weird cases of borders and rivers, particularly along the Mississippi, where it has changed course. There's a case near Wilson, Arkansas where the river has changed course, and a few square miles of land on the west side of the river belongs to Tennessee. However, for obvious practical reasons, the post office that services that area is based in Arkansas - so the same zip code crosses state lines. -Alan From: Adam Schreiber sa...@clemson.edu To: Minh Nguyen m...@1ec5.org Cc: OpenStreetMap U.S. Talk-us@openstreetmap.org Sent: Wednesday, January 28, 2009 1:38:19 PM Subject: Re: [Talk-us] County Line Corrections On Wed, Jan 28, 2009 at 4:08 PM, Minh Nguyen m...@1ec5.org wrote: Kentucky's border along the Ohio River is one example: the border is defined to be the low water mark of the Ohio-Indiana-Illinois bank as of the 18th century [1], so it's not the centerline and not quite the northern riverbank. Along Ohio's section of the river, all the islands belong to Kentucky or West Virginia. [1] http://supreme.justia.com/us/444/335/case.html So to be accurate, one has to go to county/state/judicial records individually if the higher res boundary data isn't made available somewhere online already? Adam On 1/28/09 12:53 PM, Adam Killian wrote: I think there may be cases where one shore or the other is the boundary, not the centerline. Presumably, islands in a river are in one county or the other? -- Minh Nguyenm...@zoomtown.com AIM: trycom2000; Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/ ___ 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] US Route Tagging With Relations
A couple thoughts: 1) Commercial data providers have use a route type parameter that designates something as an Interstate, Federal Highway, State Highway, County Road, or Farm-to-Market road. This code does not distinguish between states; all state highways have the same route type. General practice is to use the same highway shield for all states; you don't get the Beehive sign for Utah. :) This is an opportunity for OSM to distinguish itself; if local users contribute Highway signs from their region - down to very specialized signs for something like Kettle Moraine Scenic Route in Southeast Wisconsin - they'll have something the commercial vendors don't provide. However, there should be something clearly identify a route as a state, county/parish, farm-to-market road/ whatever, so a default shield could be picked. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. 3) There should be a place for people to contribute highway shields - as metadata. Respecifying highway shields for every route would be prone to omissions. In the case of Kettle Moraine Scenic Route - it's so specialized, it may make sense to apply the sign to the route itself. But having a place to submit a library of highway shields as metadata - that would be good. From: Zeke Farwell ezeki...@gmail.com To: Talk-us talk-us@openstreetmap.org Sent: Wednesday, December 24, 2008 7:50:20 AM Subject: Re: [Talk-us] US Route Tagging With Relations Chris, Thanks for putting up that table. Looks great. I have two suggestions: I think the network identifiers should be simpler. What about this scheme? Interstate = Interstate signed highway system US = US signed highway system [state abbr.] = State signed highway system TX = Texas CA = California OR = Oregon etc... County or other networks should just be the county name or TN Secondary, etc... To avoid duplicate network values (CA stands for California and Canada) we can use the is_in key the same way it is used for place names. So a California route relation would have these tags: network: CA is_in: United States Or a county road system in california: network: Marin Co is_in: California, United States This way we don't clutter up the network name, but we keep the differentiating information. My other suggestion is that I don't thing the symbol key is necessary. I think the renderers should be able to assign a symbol based on the network and is_in tags once they get to that stage. This way they symbols will stay more consistent and we won't get US highway shields that look slightly different throughout the country. Thoughts? Zeke ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Route Tagging With Relations
I like the idea. In GDF - a (supposedly) standard exchange format for geographic data, they have the concept of composite attributes. I think of a relation used in this way is really better described as a composite attribute that can be applied to many elements. It's best to specify highway routes in a parsed format; in other word, a highway route relationship might have the following tags. network (I, US, State, etc). route number (80) modifier(ALT,BR,BL,BUS,BYP,CONN,EXT,LINK,LOOP,SCENIC,SPUR, TOLL,TPKE,TRUCK) directional(WB, EB, NB, SB) Vanity Name(Hollywood Expy) This approach results in data that's more normalized (i.e., always use US instead of United States, US Route, Federal Hwy, etc.). Software could easily interpret it in sophisticated ways (i.e., stick 80 in a highway shield with alt above it, or print instructions Take Alternate Interstate 80 Eastbound). You can easily test if there's gaps where a route number has not been applied to a single edge (known as name rice) . If you use the network to specify highway shields, you can get sophisticated and start showing different shields for each state. It's not without potential difficulties (separate relations for eastbound and westbound lanes? Should Vanity names be included, as they usually don't extend the length of the freeway? If someone changes a tag on a relationship, they have to be sure it's appropriate for every element that's part of the relationship.) But I think this approach helps more than hurt. -Alan From: Zeke Farwell ezeki...@gmail.com To: talk-us@openstreetmap.org Sent: Tuesday, December 23, 2008 9:36:18 AM Subject: [Talk-us] US Route Tagging With Relations Hi Everyone, I've been thinking that we ought to have a standardized scheme for tagging Interstates, US Highways, State Highways, and any other numbered routes in the United States. The information I've found on the Wiki regarding US Route Tagging suggests that all information should be put into the ref tag. For example, Interstate 95 should be tagged as ref: I-95, and if Interstate 95 joins interstate 93 and they follow the same road for a while that segment should be tagged as ref: I-95;I-93. Mapnik then renders the road with a little box containing [I-95;I-93] which does not make for a pretty map. To me it seems cleaner to use the ref tag only for the route number (ref: 95). However, that would mean we lose the information about what network the route is part of. Also, what do we do about the multiple route problem? The answer is Relations! They are awesome. Mapnik doesn't render route number badges from relations yet, but it will in the future. I have been tagging routes with relations in Vermont for a while now. For example here is the tagging scheme for the US Highway 7 relation: type: route route: road network: US ref: 7 Once I've made this relation, any Way that should is a part of Interstate 91 I simply make a member of the relation. The tagging scheme for the actual way might look like this: US 7 (relation) highway: primary name: Main St ref: 7 The ref tag is not even necessary, because the information is stored in the relation, but I've included is because Mapnik doesn't yet render relation reference numbers. The best part is that when US Highway 7 and US highway 2 join for a while the tagging just looks like this: US 7 (relation) US 2 (relation) highway: primary name: Main St This solves a number of the problems surrounding the tagging of numbered routes and makes the database much cleaner. It also allows for the future possibility of route numbers being rendered with the proper shield symbol to differentiate Interstate from US Highway form State Highway. I propose that we all start using relations to tag numbered highways in the United States, and when Mapnik eventually gets around to rendering reference numbers from relations, we can stop using the ref tag on ways themselves entirely. Zeke Farwell Burlington, VT, USA ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Road classification
But - what percentage of local traffic or through traffic ends up on those roads? It's relative importance that matter. If you need to go through an area - what do you take? Same concept applied to city labelling - look at a globe some time. It's not unusual to see Thule, Greenland labelled, or Iqaluit, Nunavut. Why? Because they're the most significant towns in the area - even though they have tiny populations. On the other hand - what about San Jose, CA, 10th biggest city in the US? They always label San Francisco first - even though San Jose is bigger, with a million people. It's perceived importance. -Alan (self-conscious resident of San Jose) From: Karl Newman siliconfi...@gmail.com To: Joseph Scanlan n7...@arrl.net Cc: talk-us@openstreetmap.org Sent: Wednesday, December 17, 2008 10:04:44 AM Subject: Re: [Talk-us] Road classification On Wed, Dec 17, 2008 at 9:49 AM, Joseph Scanlan n7...@arrl.net wrote: On Tue, 16 Dec 2008, Alan Brown wrote: This is the way I like to think about it - if you're zoomed way out, a map of motorways and trunk roads alone is best: plenty of useful information, but not cluttered. This philosophy helps justify what you'll find here in the desert south west. For example, US 93 is pretty much the route one takes from Ely, through Caliente, to Las Vegas, Nevada. About 260 miles of that is two lane road. It's marked as highway=trunk not because its some grand highway along the eastern edge of the state but because it is *the* highway along the eastern edge of the state. US 95 through California (about 100 miles) is another example. Traveling from Las Vegas to Quartszite or Yuma, Arizona state route 95 is a good alternative but if a routing program insisted on Interstates one would find oneself going through Phoenix or Los Angeles. Kind of a long way to go. I should defend both highways by pointing out they don't see much cross traffic. ;-) They probably don't see much through traffic, either... Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Road classification
I'm talking more the Alaska highway, or US 50 through rural Nevada - not driveways. Or the Transcanadian Highway (Follow the only road. Follow the only road - South Park). Pick up any atlas; they'll show all sorts of minor roads in desert areas. Of course, being a private drive or barely passable road is usually a reason to not show it at all. Trunk roads and Motorways are different from primary/secondary/tertiary roads because it implies a certain physical description (I would not make Skyline a trunk road, by the way.) In Navteq data, there is a function road classification that gives the Transcanadian highway the importance as limited access highways in the US (sometimes higher; some motorways are assigned FRC 2 in their scheme, if there's a local cluster). A motorway has significant physical differences that it ought to be rendered differently; but *when* it gets rendered is a different matter. If you lived in Central Nunavut (I assume that's what you're implying about your relative importance) - maybe your place *should* show up prominently on a map. Explorers getting stuck in the ice may be hungry. -Alan From: Karl Newman siliconfi...@gmail.com To: Alan Brown adbrown1...@yahoo.com Cc: talk-us@openstreetmap.org Sent: Wednesday, December 17, 2008 10:52:55 AM Subject: Re: [Talk-us] Road classification On Wed, Dec 17, 2008 at 10:36 AM, Alan Brown adbrown1...@yahoo.com wrote: But - what percentage of local traffic or through traffic ends up on those roads? It's relative importance that matter. If you need to go through an area - what do you take? Same concept applied to city labelling - look at a globe some time. It's not unusual to see Thule, Greenland labelled, or Iqaluit, Nunavut. Why? Because they're the most significant towns in the area - even though they have tiny populations. On the other hand - what about San Jose, CA, 10th biggest city in the US? They always label San Francisco first - even though San Jose is bigger, with a million people. It's perceived importance. -Alan (self-conscious resident of San Jose) Just because it's locally important doesn't make it a trunk road, though. My driveway is locally important to me and takes 100% of traffic in and out of my garage... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging and Rendering Cycle Ways
My inclination would be to want an extra class of routes or two supported with
different network type (perhaps unlcn for unnumbered local network?) for
the lowliest of bike routes. I'm not what I'd want done for expressways.
Perhaps there could be a way to tag a road as treacherous for bicyclists,
that's still legal to ride on - or add a warning POI. I'm not sure if that
sort of information belongs in OSM, as it's subjective, but it would be helpful.
-Alan
From: Scott Atwood [EMAIL PROTECTED]
To: talk-us@openstreetmap.org
Sent: Tuesday, November 25, 2008 6:21:20 PM
Subject: Re: [Talk-us] Tagging and Rendering Cycle Ways
One other thing I'd like to add:
Expressways. Here in Santa Clara County, we have a quirky system of roads
called Expressways, which lie somewhere between normal arterials and
freeways. They tend to have few or no frontage driveways and a limited
intersections. There are some freeway style interchanges. Pedestrians are
prohibited for the most part, but bicycles are permitted on all of them. Most
of them have wide shoulders, and a few even have bike lanes on the shoulders.
Some of these expressways are excellent routes for moderately confident
cyclists. I have no idea how these expressways should be tagged for cyclists,
and any suggestions are welcome.
-Scott
On Tue, Nov 25, 2008 at 5:27 PM, Scott Atwood [EMAIL PROTECTED] wrote:
I am an avid cyclist in the San Francisco Bay Area and I have recently started
editing my local area in OSM. I would like to map all the local bike routes
and facilities, but I'm not sure of the best way to tag them in OSM. Here are
the different kinds of facilities I have encountered, and my best guess at how
to tag them.
Bike Lanes (a.k.a. Class II). This one is pretty easy. I just tag these as
{cycleway=lane}, and they render quite nicely in the Cycle Map layer. The one
problem I've encountered so far is that the existing tagging scheme doesn't
seem to handle bike lanes that are only one side of a two-way street. This is
not a common situation, but it does happen. A similar problem would apply to
sidewalks and on-street parking that are only on wide side of the street. Has
anyone proposed a solution to this class of problem?
Multi-Use Paths (a.k.a. Class I). This one is also pretty easy. I tag these
as {highway=cycleway, cycleway=track, foot=yes}. However, one wrinkle is that
these MUPs sometimes have have sections with an on-street alignment. In that
case, I added a relation to the entire MUP, both the off-street trail portions,
and the on-street alignments, that was tagged like {route=bicycle, type=route,
name=_name_of_the_MUP_}. I intentionally left off the network tag from the
relation, since this isn't part of a formal route network per se, but if
anything, it would be {network=lcn}
Bike Routes (a.k.a. Class III). This one, I'm a little bit more confused
about. These are just streets that have Bicycle Route signs on them, and
nothing more. Often, they overlap with Bike Lanes. They have no names or
numbers associated with them. I've never seen any formal map that shows bike
lanes. I've only ever stumbled across them while out on rides. They tend to
have approximately the quality of cycling conditions as Bike Lanes, without the
stripe, of course. But they are distinctly at the lowest tier of cycle
facility. I have typically been tagging these as {bicycle=designated}. One of
the other local cycle mappers has been tagging them with a relation like
{route=bicycle, type=route, network=lcn}. I'm not sure which is a better
approach. My tagging scheme feels more in line with the spirit of this type of
facility, but I suspect that to date no one is giving this a distinct
rendering. The latter scheme seems OK too, but perhaps
implies a bit more status to these routes that feels appropriate. Also, I
suspect they may render even more prominently than Bike Lanes, which doesn't
seem quite right.
Local Numbered Cycle Routes. In my local area, there is only a single
numbered local bike route, San Jose Crosstown Bike Route 11, which I
implemented as a relation like {network=lcn, ref=11, route=bicycle,
type=route}. This tagging feels about right, and renders the way I'd expect in
the Cycle Map.
Bicycle Boulevards. To the best of my knowledge, there is only one Bicycle
Boulevard in the local area, the Ellen Fletcher Bicycle Boulevard, on Bryant
St. in Palo Alto. As far as I know, no one has added the Bicycle Boulevard to
OSM yet, and I'm not sure what the best way is. Probably a relation is the
best tool to use, but I feel like a Bicycle Boulevard ought to have a distinct
rendering, since it is distinguished by lots of cyclist friendly features like
diverters for motorists, traffic calming measures, and cyclist signal priority.
I guess what I would really like is a richer set options to use tagging and
rendering bike routes,
Re: [Talk-us] Tiger Data 2007
There's another consideration ... what if a TIGER import is done somewhat carefully, but not quite carefully enough? So 90% of the areas are made better, and 10% are made worse ? If those 10% are located where someone has poured their heart into making a carefully constructed map - you could disillusion some of your most active contributors. Many would think: if a bunch of invalid TIGER roads that need to be deleted reappear in my hometown - why should I be forced to clean it up? I made it right the first time! People enter data into OSM for the sense of accomplishment. If an import improves the quality of the overall dataset in the short term - but demotivates others to contribute, because their work had been stomped on - in the long term, you may hurt data quality. I'm not saying don't import new TIGER data - I'm saying, be utterly paranoid when you do. I don't know how well the first import went - it seems it was necessary for building a base line - but you don't want to de-motivate people who contribute. -Alan From: Nick Hocking [EMAIL PROTECTED] To: talk-us@openstreetmap.org Sent: Tuesday, October 28, 2008 3:28:03 PM Subject: Re: [Talk-us] Tiger Data 2007 I don't see it as corrupting. It's not mangling the mapper's work in any way. If they don't like the new overlapping road, then just delete the TIGER one. Ok - We've hit an impass then. You can't just hit delete You have to merge all the duplicated data in order to make the way/area sane It takes much more effort than to originally edit in the new road. So you have not just mangled the mappers works you've actually turned it into negative value content for the OSM dataset. I'll leave you with one more comment that I can assure you I don't mean to be inflamatory, but I would understand if you take it so. There can only be two winners from a bulk upload of Tiger data Tele Atlas and Navteq. Nick ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger 2007 Data
Then, decide how if/when it is appropriate to write over the old TIGER stuff with new. Or, to merge it somehow. Be very, very careful here. Conflation is a difficult thing. I used to work at Tele Atlas, and there was a major project to conflate Tele Atlas North American data and GDT data (a company they just acquired). They had at least a hundred people committed full time to completing the task in a year (I don't know the exact number), with tens of millions in funding - and they failed in a big way. The head of the North American division got axed as a result. If there's a particular layer that has useful info, that's not already present - that could be imported successfully. Otherwise, the most useful thing would be some sort of set-up where someone could view changes to the new TIGER data simultaneously with the OSM data, and choose what to import. Or - if you can determine if a whole region was untouched - replace previously imported data with new data. What you don't want to mess up is the careful work people have done to improve the quality of data in a region manually. If you try to merge data automatically without careful oversight, you could destroy a lot of hard work. A one-time import - to create a starting point for people to edit - makes all the sense in the world. Subsequent updates are a much harder thing. -Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US GPS Set for Mapping Parties
As someone said, it's possible that Garmin would consider OSM a potential competitor, however that's not certain and it does us no harm to try. OSM would be a competitor to Navteq or Tele Atlas, I'd think - not Garmin. Which makes me curious - Garmin may get a small profit for repackaging the Navteq data for their device. If someone repackaged OSM data, could they build some sort of business model around that repackaging service - similar to the way Redhat makes money off Linux? With Tom Tom owning Tele Atlas, and Nokia owning Navteq, I'd think it would be in Garmin's best interest in promoting potential alternatives. OSM has a way to go to be in that position, but Garmin could easily be motivated to make some bet on it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] highway: tertiary?
I noticed the following suggested definitions for California for different road classes: http://wiki.openstreetmap.org/index.php/California For tertiary, they suggested highway=tertiary Lower traffic volumes on wide streets, or higher on narrow ones. Kinda' vague and I'm not sure I'm in agreement with these definitions, personally. I'd be even more vague :) . Here's what I think as someone who worked in a map data company for a decade: Navteq and Tele Atlas have something known as a functional road class that is used to designate the relative importance of a road for getting to your destination. During a typical trip, you would progress from roads of less-important functional road class, to more-important fucntional road class, and back down to less-important functional road class as you reach your destination. I would guess, within a mile of most urban origins, you'd expect to be on a tertiary road, and within another mile you'd find yourself on secondary road, and so forth. (Of course, if you can get to a more important road quicker, you'd use that.) Point to be made is, the functional road classification of a road might not strictly reflect the physical attributes of the road (number of lanes, speed limit, etc.) but rather, the relative importance of a road in its particular vicinity. The clearest example of this I can think of is the Transcanadian Highway. There are portions of the Transcanadian Highway that are not limited access, due to low population densities. However, Navteq gives it the most important classification level - while some Interstate Freeways, and many local limited access freeways in the US, are not assigned to that category. Point to made is, commercial data providers are somewhat subjective in their assignment of functional road class. Open Street Map's Highway attribute may be a bit different: certainly, a Motorway is a clearly defined type of road. However, when I've assigned Primary, Secondary, or Tertiary categories, I've tried to use local knowledge to reflect what the relative importance of those roads are. It will tend to track the physical attributes of the road, but not strictly. Some of it's aesthetics - I'll try to decide which primary roads should be demoted to secondary roads if the map starts looking too cluttered, or try to promote some roads from tertiary to secondary if the map looks too thin. Perhaps one secondary road between each pair of primary roads, and one tertiary road between each pair of secondary roads (although that's impossible to it exactly like that.) San Jose (where I live) has a lot of physically wide roads with moderately high speed limits that aren't used nearly as much as other roads with the same characteristics. Use the highway attribute to reflect that reality. Use explicit attributes to define number of lanes and speed limit. It's subjective. A Tele Atlas map and a Navteq map based on functional road types will look different because they made different judgements. (They do have rules to eliminate some of the subjectivity - but not completely.) That's my opinion - anyone disagree? - Original Message From: David Carmean [EMAIL PROTECTED] To: talk-us@openstreetmap.org Sent: Saturday, September 13, 2008 9:48:35 PM Subject: [Talk-us] highway: tertiary? Hi, I'm not sure if this question is within scope of this list, but I thought it might be sufficiently country-specific: when is it appropriate to use highway: tertiary in the US? Thanks. ___ 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] highway: tertiary?
Here's an example, where I used to live a short distance south of Alviso: http://www.openstreetmap.com/?lat=37.3851lon=-121.9258zoom=14layers=B000FTF See the light yellow roads that connect to other roads such as Montague Expressway and 1st St? Roads such as Lick Mill Blvd, Orchard Parkway, Plumeria? They're actually fair wide roads, and can have ~40 mph speed limits. The thing is, they're used only by people getting to local homes or businesses - they're not the main through routes. For San Jose, I've mentally come up with a system that's goes like this: Motorways are any and all limited access freeways - Highway 87, US 101, I-280 Primary highways are Expressways - or the few other roads that are similarly important. Montague Expressway, Lawrence Expressway, San Tomas Expressway, El Camino Real, Stevens Creek Boulevard: the heavy duty arterials. Secondary Highways are those roads you may take for a few miles, but are a little less important - such as Lafayette Street (which turns into Gold Street in Alviso - I wonder if I should have demoted it to a tertiary highway after it crossed under 237.) And then you have your tertiary roads. I've been subjective enough about this that I don't mind if some of these roads get reassigned, particularly in some neighborhoods I'm less familiar with. The San Jose map was in desperate need of having some sort of hierarchy of importance, so some areas I was less familiar with - such as East San Jose - I've tried to pick out the primary and secondary roads, without assigning tertiary roads. But hopefully, when you look at the map, you can quickly decide: what are the main roads I'd used to get to a neighborhood? What are the main roads within a neighborhood? That's another way to think of secondary and tertiary roads. -Alan - Original Message From: David Carmean [EMAIL PROTECTED] To: Alan Brown [EMAIL PROTECTED] Cc: talk-us@openstreetmap.org Sent: Sunday, September 14, 2008 12:11:42 AM Subject: Re: [Talk-us] highway: tertiary? Alan, I live in the Bay Area and in fact will probably be augmenting some of your work down around Alviso and Sunnyvale; do you have any examples where you've actually chosen to use highway=tertiary? On Sat, Sep 13, 2008 at 09:57:52AM -0700, Alan Brown wrote: I noticed the following suggested definitions for California for different road classes: http://wiki.openstreetmap.org/index.php/California For tertiary, they suggested highway=tertiary Lower traffic volumes on wide streets, or higher on narrow ones. Kinda' vague and I'm not sure I'm in agreement with these definitions, personally. I'd be even more vague :) . Here's what I think as someone who worked in a map data company for a decade: ___ 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] Excess TIGER nodes in a way
I can say what I do ... First I'd verify that there's no extra information attached to nodes that I'd consider deleting. :) Then I'd make a judgement: as the nodes are positioned now, do they make the road look a little crooked in a way it really isn't? If it does, I start thinning. The nodes are eating up space in the database, but are not contributing to the quality of the information. If it has more nodes than necessary, but it's straight as an arrow - I usually leave it alone. On a dual carriageway, it usually improves the appearance if you position the nodes on each side at the same position. This makes it easier to keep the carriageaways a constant distance apart. Another rule of thumb - if the nodes do not represent something physical (such as a junction of two roads) - the tighter the radius, the more nodes there should be per unit distance. But even for straight roads, I think it's good to maintain a maximum distance between nodes - perhaps a mile. If you keep nodes too far apart, moving one node will impact something that's far away. By the way, the biggest value in rendering roads as a dual carriageway, is that it provides a natural way to express a lot of information about physical turn restrictions; it's not just for appearance. Be careful about how you connect cross streets - if they connect to both carriageways, connect the cross street to both via nodes. If it's an underpass or overpass, connect nothing. If it just connects to one carriageway, connect to it. -Alan - Original Message From: Joseph Scanlan [EMAIL PROTECTED] To: Talk-us@openstreetmap.org Sent: Thursday, August 21, 2008 10:10:52 AM Subject: [Talk-us] Excess TIGER nodes in a way There's a question at the end but I'll start with a little background. Last weekend I took a drive that included US 93 in Arizona. Naturally, I wanted to compare my GPS trace, the Yahoo images, and my memory to the OSM data. Much of this piece of US 93 is divided highway (is this also called a double carriage way?) but the TIGER data in OSM shows a single primary way. I moved the existing way to the northbound side of the highway and drew a fresh southbound way. They are both tagged highway=primary, oneway=yes, ref=US 93, and name=United States Highway 93. The TIGER tags remain on the northbound side but are not duplicated southbound. So far I'm happy with this. Parts of this highway are quit straight: http://www.openstreetmap.org/?mlat=35.396938mlon=-114.259680zoom=14 The northbound way has (mostly) all the nodes from the TIGER data. Southbound only has as many as I needed to connect to other ways, copy the shape of the northbound way, and a few more where a northbound node might have marked something in the image but there wasn't a way in the data. This part bothers me. Now the question. Should I 1) delete the (what I believe are) extra TIGER nodes from the northbound way, 2) add a bunch of nodes to the southbound way to make it match northbound, or 3) call it done and learn to be happy? -- - Joseph Scanlan http://www.qsl.net/n7xsd +1-702-455-3679 http://n7xsd.dyndns.org [EMAIL PROTECTED] (work) (not work) [EMAIL PROTECTED] - So he went inside there to take on what he found. But he never escaped them, for who can escape what he desires? --Tony Banks of Genesis in The Lady Lies ___ 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] Bicycle facility tags (Class III bike route)
I've been working on something similar for San Jose ... I've been working on the seperate cycle tracks, but I'll eventually get to the roads. Are there any server set up there rendering North American (or, at least, Bay Area) tiles similar to the OSM cycle map? http://www.gravitystorm.co.uk/osm/ I'd also be curious - does mapnik have the ability to render partially transparent PNGS, to use as an overlay? - Original Message From: will law [EMAIL PROTECTED] To: Karl Newman [EMAIL PROTECTED] Cc: talk-us@openstreetmap.org Sent: Tuesday, August 12, 2008 5:08:27 PM Subject: Re: [Talk-us] Bicycle facility tags (Class III bike route) On Tue, Aug 12, 2008 at 4:34 PM, Karl Newman [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 4:11 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Class I is the separated bike path, with a physical separation between the bicycle path and vehicle traffic, or on a route which other vehicle traffic doesn't follwo. This one is easy, you trace in the path, and make it highway=cycleway; cycleway=track. It's just the same as drawing in separate roads for divided roads. Class II is the bike lane with its own lane markings, but it is immediately adjacent the vehicle lanes. This also seems to be pretty clear: just add a cycleway=lane tag to the road it is part of, right? Class III is a shared use facility with the cars, it just has the green bicycle route signs occasionally. Hopefully it has a wide outside lane, but not always. How do you put this one in? do you add a bicycle=designated tag to the road, or what? I have been classifying Class I II cycleways in San Francisco using the above method. I haven't got on to the Class III type but bicycle=designated seems appropriate to me. I think your suggestions line up with how I would tag it, too. I'm curious where you heard about the Class I, II, III designations, though. I'm a California native and occasional bike rider and I've never heard of these. Karl Here's the detail on their classification in California. I'm not sure if the same is used elsewhere in the US though: http://www.leginfo.ca.gov/cgi-bin/displaycode?section=shcgroup=1-01000file=890-894.2 Will___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
