Re: [Talk-us] TIGER fixup and mapping more
On 7/12/2012 11:27 AM, Clay Smalley wrote: I like this idea. That would encourage more people to TIGER-review streets, as highway=road shows up pretty ugly on Mapnik, and people like getting rid of ugly. What would be the drawbacks of doing this? It seems like there would be some but I can't think of any. The problem is that you can easily see that any old subdivision street is residential on an aerial, but you shouldn't remove tiger:reviewed unless you've verified the name. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] railway=abandoned and mapping things that are not there any more?
On 7/12/2012 11:43 PM, Peter Dobratz wrote: NE2, So after I bring up that I don't think railways should be drawn through buildings, and most people agree with me on that, you decide to do this: http://www.openstreetmap.org/?lat=42.762886lon=-71.430509zoom=18layers=M Does 86 Central Street, Hudson, NH have remnants of a railroad running through their living room? No, because that's ridiculous. Is it on the former route of a railway? Of course. And that's what railway=abandoned has meant since I joined OSM. Maybe you could hold off dumping stuff on top of work that I've done while we continue to discuss the matter. Back at ya. Don't delete something that doesn't interest you. Does anyone have any objection to reverting the following changesets?: http://www.openstreetmap.org/browse/changeset/12202043 http://www.openstreetmap.org/browse/changeset/12186087 http://www.openstreetmap.org/browse/changeset/12191431 For the record, I do object. And the fact that you would consider killing a fly with a sledgehammer is disturbing. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] railway=abandoned and mapping things that are not there any more?
On 7/12/2012 10:45 PM, Mike N wrote: On 7/12/2012 4:21 PM, Nathan Edgars II wrote: This is a strawman, since there will rarely be more than one former line across a small area. Correct me if I'm wrong, but I don't think anyone wants to map all the former second tracks, sidings, and such, especially where they've changed over the years. That's just what the local mapper was doing. I ended up deleting a bunch of old spurs that wound through the city and passed through buildings. I can buy former spurs, though I'll usually only map them if they're significant in length or history or there are still remnants. Was this mapper adding multiple tracks on the same right-of-way? A single abandoned track would be no more of a problem than a power line. Or an underground sewer line. Or an administrative boundary. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
On 7/11/2012 8:38 AM, Frederik Ramm wrote: Hi, On 07/11/12 13:59, Mike N wrote: The state capital region of Columbia, South Carolina will be a prime test of the Do empty areas attract contributors? theory for some time to come. Why, is someone planning to remove the TIGER import in that area? Yes, wherever those TIGER ways were either outright deleted or combined with other ways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
On 7/11/2012 9:31 AM, Frederik Ramm wrote: Hi, On 07/11/12 15:20, Nathan Edgars II wrote: The state capital region of Columbia, South Carolina will be a prime test of the Do empty areas attract contributors? theory for some time to come. Why, is someone planning to remove the TIGER import in that area? Yes, wherever those TIGER ways were either outright deleted or combined with other ways. Obviously my comment was a bit tongue-in-cheek; I am personally convinced that the unedited TIGER landscape - i.e. a map of which virtually nothing is correct Nope. and once you start to work somewhere you have to touch almost every single object if you want an acceptable result - is the worst situation for attracting mappers. Therefore, returning an area to how it was after TIGER (and deleting selected objects for good measure) is certainly not creating an empty area in the sense of the do empty areas attract contributors theory. My comment was serious. Where an ungood user has done a lot of editing to TIGER ways, the OSMF will not return it to the TIGER state, but will leave a horrible mess of half-deleted TIGER. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
I've just ensured that the OSMF will do minimal damage to the U.S. railway network outside the Los Angeles area. Most of the damage will be moving nodes, meaning that geometry may be totally borked but topology will be fine. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
On 7/10/2012 5:40 PM, Nathan Edgars II wrote: I've just ensured that the OSMF will do minimal damage to the U.S. railway network outside the Los Angeles area. Oh, and South Carolina. Not going to touch that. Most of the damage will be moving nodes, meaning that geometry may be totally borked but topology will be fine. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
On 7/10/2012 6:15 PM, Charlotte Wolter wrote: Nathan, How did you ensure that the railroads will be damaged minimally Using JOSM's license change plugin. If the OSMF uses a different algorithm, we're all screwed. (and why is poor old LA excluded)? Because there's a lot of work and I can only take so much of digging holes and filling them back in. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Road route relation conventions
On 7/9/2012 6:23 PM, Mike N wrote: Is there a Wiki page that describes the best current highway tagging scheme to document use of route relations and refs to support Mapnik with shields and other data consumers? No, because there is no current tagging scheme :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Scenic/Historic byways
On 7/8/2012 3:20 PM, Toby Murray wrote: Just came across this while processing pictures from my bike across Kansas: http://i.imgur.com/bmiV2.jpg This is a sign for the Western Vistas historic byway. It even has a website: http://www.westernvistashistoricbyway.com/ Closer to home I have also seen a Scenic Byway sign. This seems to be an official designation by the US DOT as discussed here: http://en.wikipedia.org/wiki/National_Scenic_Byway I'm not seeing nearly as much information on historic byways. Are these designated by the DOT as well or are they just tourist attractions? They're at least approved by the DOT if they run along state highways. I've used scenic=yes for some in Florida. For example: http://www.openstreetmap.org/browse/relation/1239925 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rails with trails
On 7/3/2012 4:11 PM, Anthony wrote: What if it's an abandoned railway which is adjacent to a not-abandoned railway? Then it's already tagged as a rail trail. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shorelines of highly variable lakes
Note that if you have the desired surface level, you can use USGS topos to place the shoreline on the correct contour. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rails with trails
On 6/27/2012 10:46 PM, Paul Johnson wrote: Ideally a map of rail trails should include them (e.g. the one in Trains magazine's May 2011 issue), but there's no easy way to determine if a trail is one. I would map the ways independently when the trail is adjacent to the rails. Duh? The question is what *additional* tags to put on the trail. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] An amusing story of a GNIS entry
http://www.fuzzyworld3.com/3um/viewtopic.php?f=29t=3183 I suppose the question is whether OSM should have this place (assuming someone verifies that the sign is gone). Currently it does as part of the GNIS import: http://www.openstreetmap.org/browse/node/153418203/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Rails with trails
Currently it's simple enough to find most (correctly-tagged) rail trails in the database: find anything tagged railway=abandoned and highway=[one of the trail values]. These trails are usually flatter than roads, and are therefore well-suited for long-distance cycling. But another popular kind of rail trail, a rail with trail, cannot be found in this manner. Generally the railway company will lease part of its right-of-way to the trail organization, with a fence separating the rail from the trail. (This is possible because a large number of main lines had at least two tracks in railroading's heyday.) This may be a self-contained trail, or a portion of a longer 'standard' rail trail that shifts to the side where a short piece of the rail is still in use. These trails have the same features as rail trails, with the possible bonus of being able to watch trains on an active railroad. Ideally a map of rail trails should include them (e.g. the one in Trains magazine's May 2011 issue), but there's no easy way to determine if a trail is one. Does anyone have any ideas for tagging? The simplest would be something like rail_with_trail=yes or maybe railway=adjacent. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Work on Arizona rail lines deleted
On 6/19/2012 1:27 PM, Charlotte Wolter wrote: Dear US folks, I did a lot of work on the railroad that parallels I-40 across Arizona, from Gallup, N.M., to Flagstaff, Ariz. There are two parallel tracks with different names, Not sure what you mean by this. The Gallup Subdivision (Belen-East Winslow) and Seligman Subdivision (East Winslow-Needles) both operate (at least east of Seligman) using centralized traffic control on 2+ main tracks. but OSM had only one of those tracks. I added the second rail way and numerous side tracks, following the Bing imagery. It was hours and hours of work. Now someone has deleted most of the second line without contacting me or discussing the issue on the mail list. Anyone know anything about this? I assume you're talking about east of Holbrook. It's hard to tell, but looking at http://www.openstreetmap.org/browse/way/137620560/history in JOSM before and after changeset 10173363, I see that it's now on the south track but had been on the north track. In that changeset, you deleted one of the ways (a two-node crossover) you had previously added: http://www.openstreetmap.org/browse/way/137364047/history and you deleted a node where the siding had joined the north main track: http://www.openstreetmap.org/browse/node/1506904532/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Los Angeles area status
On 6/14/2012 9:31 PM, Alan Mintz wrote: I'm not sure I blame him, in theory, for not agreeing to something unseen, being solely at the mercy of the masses - the same ones that approved this change to begin with. Actually there wasn't even that level of approval. The current license change never went to a vote (all the votes people will cite are to move forward with the process of planning for a possible license change). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Seeing things you don't care about in the database
On 6/11/2012 7:17 PM, Mark Gray wrote: On one hand, I share the frustration of having lots of new data in an area making some of our tools slower and more difficult to use. In my area a building footprint import slowed down most of the mapping tools and land use polygons can get in the way of editing roads. I agree with this. But I'm not sure that there is a solution. You can use XAPI/Overpass API to download only roads in an area, but you get conflicts (or worse, you move a node and screw up something else without realizing it) when nodes are shared with other non-downloaded features. This can happen directly (road passing through a building or the IMO bad practice of using roads as landuse borders) or indirectly (e.g. road - parking lot - building - landuse). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Import guidelines review
On 6/6/2012 3:11 PM, Tirkon wrote: Worst Fixerworstfi...@gmail.com wrote: It means that we must revert things like TIGER and CanVec. Am I right? I think fundamentally you are right with this point. My impression is that many people at OSM regret these imports - in fact the longer they are involved in the project. Most opinions I've seen are that TIGER is imperfect but better than nothing as a starting point. I imagine Wikipedia would have been imported so far and the user were damned to correct it and only add bits and bobs. I am pretty sure it never ever would have had that success it had. Pull up five articles on small-to-midsized U.S. cities in English Wikipedia. You'll probably see many similarities. This is because they were created in the early days of Wikipedia by user Rambot, using US Census Bureau data (which TIGER also happens to be). IMHO the community impact of imports should be described in extenso before any technical stuff is mentioned. And yes - it should be mentioned that TIGER and its friends were early mistakes of OSM. This view that they were mistakes is far from widespread. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Menlo Park Admin Boundary
I forgot to mention that you can also use Potlatch 1. Hit U to view deleted ways, select the way, and unlock. This is probably the easiest for a simple undeletion like this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Special issues in LA remap
On 6/5/2012 3:42 PM, Mike N wrote: On 6/5/2012 2:56 PM, stevea wrote: But socially, or more properly stated, in the context of reaching OSM consensus, what does our community think of (rather wholesale) reverts of a contributor who has not agreed to the CT? Are we OK with that? This nearly describes what the redaction bot will do, once it is complete. With one big difference: the bot will not undelete objects that an ungood mapper deleted. (So any joining of ways by such a mapper will be handled improperly.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] User cleared out a chunk of streets
On 5/31/2012 11:33 AM, Brian May wrote: Hi All, I just noticed in Gainesville, FL user AMPINTERMEDIA http://www.openstreetmap.org/user/AMPINTERMEDIA recently deleted a chunk of streets from one section of town. Doesn't look sinister - they are a new user and probably didn't realize what they were doing. The account name matches a local SEO company in Gainesville. I'm not sure what to do about it, i.e. I'm not sure what the protocol is for this type of situation and I've never attempted a revert before. Can someone review this and revert it? http://www.openstreetmap.org/browse/changeset/11624008 Reverted (the only creation rather than deletion was a misspelling of a school that was already there). If you haven't messaged him yet, you should probably let him know. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] proposed automated edit: forested wetlands
On 5/29/2012 6:04 AM, Nathan Edgars II wrote: The landuse import for Georgia (which IMO is poor-quality and should be deleted, but that's not going to happen) has a bunch of areas tagged as note = Forested Wetland with no useful natural=* tags (since natural=wood and natural=wetland both apply). Example: http://www.openstreetmap.org/browse/way/31457349 I propose to fix these. But what would be the best tags to use? Would natural=wetland wetland=swamp (An area of waterlogged forest, with dense vegetation.) be correct? If there are no objections, I'm going to do this sometime today. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] proposed automated edit: forested wetlands
On 5/30/2012 6:19 AM, Frederik Ramm wrote: There's absolutely no reason to rush. Data that's been sitting in OSM for *years* without even being noticed as a problem I noticed it as a problem about a year ago. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] UK assumptions that don't hold in the U.S.
I've noticed some odd things on OpenCycleMap and other renderings, and I think it's due to a difference in how things are in the UK vs. here. *Most railways have passenger service. Thus OCM (and the transport map) show all rail lines. *Tracks are useful for cycling. When you zoom in on OCM, tracks are highlighted the same as footways. But a track is just a narrow (usually) unpaved road, and is worse for cycling than a low-traffic paved road. This also shows up on renderings such as http://www.itoworld.com/map/26 where tracks are included in path/cycle-path etc rather than road. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] proposed automated edit: forested wetlands
The landuse import for Georgia (which IMO is poor-quality and should be deleted, but that's not going to happen) has a bunch of areas tagged as note = Forested Wetland with no useful natural=* tags (since natural=wood and natural=wetland both apply). Example: http://www.openstreetmap.org/browse/way/31457349 I propose to fix these. But what would be the best tags to use? Would natural=wetland wetland=swamp (An area of waterlogged forest, with dense vegetation.) be correct? Or is it better to choose natural=* tag and add a multipolygon for the other? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UK assumptions that don't hold in the U.S.
On 5/29/2012 10:00 AM, Frederik Ramm wrote: Hi, On 05/29/12 11:57, Nathan Edgars II wrote: *Most railways have passenger service. Thus OCM (and the transport map) show all rail lines. But isn't a railway an obstacle for cyclists no matter what services they support? Sure. But that would support their being shown at close zooms, not all the way out at 7. On 5/29/2012 10:16 AM, James Umbanhowar wrote: Many tracks are quite usable by bikes with big tires, e.g. mountain bikes. Agreed. But so is every paved road. What OCM does is give more prominence to a track (even one marked access=private!) than a residential street, for example right in the middle of here: http://www.openstreetmap.org/?lat=28.3866lon=-81.2697zoom=13layers=C ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Topo map source?
On 5/28/2012 1:58 AM, Russ Nelson wrote:
Do we have a new source for WMS topo maps now that Terraserver
(msrmaps.com) has been shut down? Can I get a working URL from
somebody?
wms:http://raster.nationalmap.gov/arcgis/services/DRG/TNM_Digital_Raster_Graphics/MapServer/WMSServer?FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=1,24,10,16,7,21,23,4,9,20,11,18,13,3,0,17,22,19,2,5,14,8,15,12SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}styles=
It's not perfect (some topos are misaligned and some are missing).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] How do I fix dupe nodes in waterways?
On 5/20/2012 8:22 PM, James Umbanhowar wrote: I'm guessing that if you remove all the (superfluous) NHD:xxx tags, they will then become duplicate nodes in waterways, which I think can still be fixed in JOSM. Nope - removed all but waterway=* and I have the same problem. I've noticed boundary duplicated nodes showing up in errors and being fixable, but even removing all tags and adding boundary=administrative doesn't help in this case. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tagging cul-de-sacs
On 5/15/2012 2:23 PM, Alan Mintz wrote: At 2012-05-15 11:19, Clifford Snow wrote: I tag culs-de-sac as turning_circles and only draw a circular way when there is an island in the middle. But I have a question. Where should the turning_circle node be placed? In the middle of the culs-de-sac or where the street enters the culs-de-sac? The center of the circle, like any other node meant to represent an area. If the street is straight leading into a turning circle that's on one side of the road, I'll usually keep it straight and put the node on the edge of the circle. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Vandalism by ZeGermanata needs sorting out
http://www.openstreetmap.org/user/ZeGermanata/edits Vandalism includes the following: http://www.openstreetmap.org/browse/way/21523281/history changing ref=US 41 to US 241 http://www.openstreetmap.org/browse/way/163035927/history fake motorway bypass http://www.openstreetmap.org/browse/way/162757131/history fake subway woodpeck_repair reverted some *but not all* of the vandalism (for example, US 241 is still tagged as such). Subsequent edits have also been made by Tom Layo e.g. here: http://www.openstreetmap.org/browse/way/17892247/history So reverting is complicated. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] U.S. inland waterways
Is anyone familiar with the regulations governing the U.S. inland waterways (such as the Mississippi River and the Intracoastal Waterway)? From my brief look, it seems to be less these barge configurations are allowed and more you can go anywhere but don't crash. Is this correct, or are there defined maximum sizes? In either case, any idea what the suitable tags might look like (other than the generic boat=yes ship=yes)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U.S. inland waterways
On 5/16/2012 1:06 AM, Jeffrey Ollie wrote: In either case, any idea what the suitable tags might look like (other than the generic boat=yes ship=yes)? I guess that depends on what you're trying to do... If you are trying to tag the largest possible vessel that can navigate a waterway (under normal conditions at least) you could probably come up with a reasonable set of tags. Inland waterways are highly dynamic though... I'm trying to do something like the European tagging: http://www.itoworld.com/map/24 But there they have some sort of international treaty that defines configurations. Do you know of any reasonable way to define large vs. small? I know there's deep-draft shipping, but most inland waterways don't support that (since barges are apparently shallow-draft). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER road expansion code
On 5/12/2012 12:41 PM, Serge Wroclawski wrote: What error rate is acceptable? As low as possible, but I've been generally able to handle the edge cases I've seen, either by doing the right thing, or by punting and doing nothing at all. It's worth noting that any errors are already there as errors in the TIGER tags. So, had the TIGER import been done properly in the first place, these errors would be in the name tags as well. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
The process seems obvious to me: check that the name is still what it originally was (from the tiger:name_base etc. tags), and if so, use those tags to expand abbreviations. (Ignore any with semicolons/colons from joining.) If not, set it aside for semi-manual checking. The only false positives that are not errors in the TIGER data will be caused by someone changing the tiger tags, and if both these and the name were changed consistently, the editor probably knew what they were doing. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 10:03 AM, Paul Johnson wrote: On Mon, May 7, 2012 at 6:59 AM, Nathan Edgars IInerou...@gmail.com wrote: Same here. I'm ignoring this wiki-fiddling: http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dmini_roundaboutdiff=747981oldid=689543 Both edits you mention seem to agree that the island is traversable in a mini roundabout. It had said usually does not have a physical island. This was changed to an absolute. And actually this was the start of it: http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dmini_roundaboutdiff=605002oldid=515047 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 11:02 AM, Paul Johnson wrote: On May 7, 2012 7:06 AM, Nathan Edgars II nerou...@gmail.com mailto:nerou...@gmail.com wrote: On 5/7/2012 9:59 AM, Paul Johnson wrote: On Mon, May 7, 2012 at 6:51 AM, Ian Deesian.d...@gmail.com mailto:ian.d...@gmail.com wrote: I've mapped dozens of these as miniroundabouts in the midwest: http://g.co/maps/w7mnr That's not a mini, though, since you can't just drive over the island. And highway=motorways aren't restricted to motorized traffic only, and not all highway=trunk are trunk roads (even in the UK). That doesn't seem to address the fact that mini roundabouts are mini in terms of height, not diameter. It vaults right over any supposed definition of mini-roundabout. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 12:41 PM, Paul Johnson wrote: On Mon, May 7, 2012 at 8:05 AM, Nathan Edgars IInerou...@gmail.com wrote: It vaults right over any supposed definition of mini-roundabout. I suppose if you ignored the whole traversability or vertical clearance requirements the wiki's had since the tag was created in the wiki, sure. I ignore that in favor of how the tag actually gets used in the data. A couple watchdogs can keep the wiki saying one thing, but they can't keep usage from diverging. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 1:02 PM, Paul Johnson wrote: Still, the diverging use overlaps improperly with the actual roundabout correctly as a ring using junction=roundabout. ;o) You're assuming that each real-world situation has only one correct way of mapping. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 1:16 PM, Paul Johnson wrote: On Mon, May 7, 2012 at 10:14 AM, Nathan Edgars IInerou...@gmail.com wrote: On 5/7/2012 1:02 PM, Paul Johnson wrote: Still, the diverging use overlaps improperly with the actual roundabout correctly as a ring using junction=roundabout. ;o) You're assuming that each real-world situation has only one correct way of mapping. So, you're suggesting we stop mapping nontraversable, hard medians? Because that's what it sounds like. Get your ears checked. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
On 5/7/2012 4:28 PM, Nathan Mills wrote: So this is not/should not be a mini_roundabout? It seems a little silly to call it anything else, since the city just dug a hole in the center of the existing intersection, built a circular curb, and planted a tree: http://g.co/maps/e2gsv Even sillier: according to the wiki, http://jemappellewendyi.wordpress.com/2010/10/28/imagen/portable-roundabout/ must be mapped as a circular way. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] First bona fide mini-roundabout spotted
The problem seems to be that mappers needed a tag for a small roundabout on a node. Since all that was available was mini_roundabout, that's what we used. Had there been another tag, e.g. highway=roundabout, we wouldn't have this discussion. But mini_roundabout is now in use for a large number of miniature roundabouts that may not be strictly mini-roundabouts. There's been a similar case recently with surface=cobblestone apparently not being real cobblestone but something called 'sett'. Someone tried to change the tag definitions, but it was way too late. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed Fresno fixes
On 5/6/2012 1:39 PM, Nathan Mixter wrote: 2. Align the shapes to match what is on the ground. I plan to either get rid of or modify them so they match what is on the ground. I'm not sure how you plan on doing this. Many times a fence will be on one side of the property line, to avoid dealing with a neighbor. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
On 5/4/2012 2:42 PM, Apollinaris Schöll wrote: any import should be treated like this. if it's not edited and the data isn't used then it should be removed after some time. That's a silly statement. If something isolated gets imported, e.g. a water political boundary, it probably won't be edited. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On 5/1/2012 1:23 PM, Anthony wrote: On Tue, May 1, 2012 at 1:18 PM, Nathan Edgars IInerou...@gmail.com wrote: On 5/1/2012 12:59 PM, Anthony wrote: Automatically expanding abbreviations is a terrible idea. If an abbreviation is unambiguous, then it can be expanded during the preprocessing step. If, on the other hand, it is ambiguous, then you are turning ambiguous data into incorrect data, which certainly diminishes the data. Not quite. We have various TIGER tags that break the name into pieces, and allow automated expansion where the name field may be ambiguous. (Though occasionally these tags are wrong.) I'm not sure what you're disagreeing with. Either it is unambiguous (due to TIGER tags or whatever), and therefore can be done during the preprocessing step. Or it is ambiguous, and needs human intervention/review. The TIGER tags are not exactly standard OSM tags that belong in the database. Better that we get rid of them at the same time as we expand abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Waterway directionality in drainage canals
It's the standard to draw a waterway in the direction of flow. I've questioned this several times, but it's an ingrained default. My question is more specific: what happens to a drainage canal that reverses direction? I offer the Everglades and surrounding agricultural land as an example. There are huge water conservation areas that store water. When it rains, gates are closed and opened to direct water into these. During a drought, gates send water back out into the canals for local use. When there's a big storm, water will instead go directly out to sea. So there are a lot of major canals that have no fixed direction. How should these be mapped? Is there any existing scheme that can show how water flows under different conditions? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
On 4/26/2012 2:54 AM, Paul Norman wrote: I happened across an import of Fresno castradal data from mid-2010 in the Fresno area. http://www.openstreetmap.org/?lat=36.77lon=-119.81zoom=15 is the general area but I haven't fully explored the extents. For a view of the data, see http://maps.paulnorman.ca/imports/review/fresno.png The biggest problem with this import is that it's impossible to download any reasonably-sized area of Fresno for editing, because of how the landuse polygons end at every street and alley. It's even worse in the suburbs where the streets curve, adding many nodes to each way. (By the way, the word is cadastral, not castadral. And I see nothing wrong with using such data as part of a semi-manual process of creating larger landuse polygons for neighborhoods, and commercial strips surrounding highways. See Orlando, FL for a (mostly fully-manual) example of how this works.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, etc. Points or outlines
On 4/24/2012 2:38 PM, Josh Doe wrote: Yes, there should be only one feature for each real world object, and the way/multipolygon has more spatial information, however the nodes might have other useful information like the GNIS feature ID. For this matter, why are there county nodes all over the U.S.? They don't seem to have come from GNIS: http://www.openstreetmap.org/browse/node/316947053/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, etc. Points or outlines
On 4/24/2012 10:21 PM, Toby Murray wrote: I think the reason they exist is the same reason why cities always have a node in addition to their administrative boundaries. And states/countries too far that matter. Most renderers render the name from the nodes, not the admin boundaries. This makes sense for a city, where the center/downtown is not the centroid. But for a county or larger, you usually want the label at the centroid of the polygon, so the node is redundant. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 3:29 AM, Werner Poppele wrote: I totally agree with Frederik. Yes - imported data turns down new mappers. Have you ever seen those monster multipolygons ? I am sure a new mapper says: Forget that I personally tend to stop my contribution to OSM because of the very bad stuff I see when mapping: Triple contours at the same position, double / triple nodes, unconnected, tiny streams / rivers with a bunch tags. You seem to be arguing against *bad* imports, not imports in general. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 4:26 AM, Frederik Ramm wrote: And now assume there's a third city of equal size where *nothing* has been mapped at all... maybe I shouldn't speak for everyone but for me (and virtually every mapper I know) surely the city with data-but-no-mappers would be least appealing, far below that with no data. You definitely shouldn't speak for other people. I would much prefer imported street data to nothing at all, and James indicated that he would too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 8:18 PM, Serge Wroclawski wrote: If a user manually surveys data, there is an assumption of timeliness and accuracy of that survey. That's not the case with imported data, despite oftentimes being stamped official. When I joined OSM I went through photos and notes I had taken since the late 1990s. There's no guarantee of timeliness here either. Certainly not as much as an import of city boundary data that has each annexation marked through the current year. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Smooth shoulder intended for cycling
I'm wondering what the best way would be to tag a good-quality shoulder that acts essentially as an undesignated bike lane, in that you can use it but it is not required. Current Florida DOT policy is to use these on rural roads, with marked bike lanes only when there is a lane to the right. For example here: http://maps.google.com/maps?hl=enll=30.605358,-86.950672spn=0.008255,0.016512gl=ust=mz=17layer=ccbll=30.605241,-86.950558panoid=X4-X3CdhvVO_ptMWbvB8SAcbp=12,330.83,,0,9.24 One can choose to ride either in the right lane or on the shoulder beyond the intersection. One regional mapper uses cycleway=shoulder for this, but I see that as sub-optimal, since it's primarily a shoulder, not a cycleway. It would be like putting cycleway=sidewalk whenever there's a smooth paved sidewalk. On the other hand, shoulder=yes or shoulder=paved says nothing about the quality of the shoulder. Should there be a minimum width for a shoulder (FDOT's standard is 4 feet)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 9:23 PM, Serge Wroclawski wrote: On Tue, Apr 17, 2012 at 8:52 PM, Nathan Edgars IInerou...@gmail.com wrote: When I joined OSM I went through photos and notes I had taken since the late 1990s. There's no guarantee of timeliness here either. Certainly not as much as an import of city boundary data that has each annexation marked through the current year. Don't worry, I wasn't counting you NE2- according to your own profile, you use a made up name, and according to your editing patterns, you're a bot, so you're more of an import than a user. Ah, the old ad hominem. When you can't reply, be a dick. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Smooth shoulder intended for cycling
On 4/17/2012 9:43 PM, Kristian M Zoerhoff wrote: Alternatively, maybe cycleway needs an unmarked lane setting for these situations, though that would imply the local authorities are intending for cyclists to use the shoulder, rather than just tolerating their presence (the usual situation). I use cycleway=unmarked_lane for FDOT's undesignated bike lane, which has a white line on the right side but no bike markings. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
On 4/16/2012 8:56 PM, Alan Mintz wrote: So, we're basically duplicating the existing way and then blessing it. Is this really sufficient - to verify the tainted geometry instead of re-drawing it? Only if the nodes are clean. Another point, at least in SoCal, is that many of our tainted ways are created by blars, who has not accepted the CT. However, these are TIGER-imported ways. They carry the TIGER tags. I'm sure they could be verified as having come from the TIGER import. They were no-doubt the result of having split an existing TIGER way. In this case, why is it not sufficient to see the TIGER tags on the way to consider it blessed along with all the other TIGER ways? Especially when tagged afterwards by accepting mappers with sources as above? Because the OSMF is lazy and wants us to do the work in identifying false positives :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
On 4/16/2012 9:18 PM, Alan Mintz wrote: At 2012-04-16 14:06, Nathan Edgars II wrote: Or you can simply add odbl=clean if there's nothing ungood about the object (e.g. it was split from a TIGER way and the splitting is something you would have done anyway). Is this really sufficient? Can someone from the redaction squad comment? Can I protect/bless a way or node and prevent its redaction simply by (in good faith) adding this tag? We have no idea what rules the OSMF will use. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
On 4/16/2012 11:04 PM, James Mast wrote: I just saw this post on the rebuild list, so you guys might want to be a tad careful when you're doing cleaning work by creating a new way and keeping the old tainted nodes in it. http://lists.openstreetmap.org/pipermail/rebuild/2012-April/000206.html Frederik is slightly exaggerating, in that it's OK to do so if all the contributors of any data you're keeping have agreed to the CT, even if you yourself have not surveyed or traced it. (Otherwise we'd have a major problem whenever a way is split.) In fact I believe Frederik has done this sort of copy-paste into a new object when the history of a relation has become too large. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
One possible enhancement: add a border of the same color as the highway (e.g. red for primary). This would make it easier to identify which highway the shield refers to, which isn't always clear. This may of course be very complicated, in which case never mind. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/14/2012 2:38 PM, Phil! Gold wrote: If you count out all the emails on the subject, there are probably more emails opposing the network-classification-per-banner approach, but if you count the people expressing opinions on the matter, network-classification-per-banner has a strong majority. If this is so, the wiki and data needs to reflect that the network tag is not a network tag. That's why I started the recent discussion about whether network should actually represent the shield design, and there was no consensus. This is not necessarily a bad thing. Foot paths can be tagged in multiple ways. Renderers and tools need to be able to handle them all. It's not the renderer's place to tell us how to tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Gated communities - access=private or destination?
In the U.S., a gated residential community usually allows anyone in who has a legitimate reason to be there (e.g. visiting a friend, delivering a package, repairing a TV). It seems that this fits access=destination as well as private. Would it be reasonable to tag it as such, and leave access=private for secondary entrances that lack a guard and can only be opened by residents? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/13/2012 8:42 AM, Phil! Gold wrote: First off, I still feel that there was a consensus last year on using the network tag for distinct network subsets as well as for mainline roads and you, despite being the only dissenter, continue to argue against something the rest of community more or less settled on. Whether or not there was a consensus last year, it's clear that there is none at the present time. See the recent thread about the network tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/12/2012 2:59 PM, Phil! Gold wrote: * Minh Nguyenm...@1ec5.org [2012-04-12 10:06 -0700]: There's an ALT I-75 that needs its own sequence file I had no idea there were alternate Interstates. I added it under network=US:I:Alternate, ref=75. (Right now, it's rendering as regular I-75.) Sounds like a bug in the rendering. However, I wouldn't necessarily oppose a separate network tag in this case, since it's clearly not part of the Interstate Highway System. (The same would apply to business Interstates.) Michigan has some 'emergency' Interstates that are essentially detours, but are permanently signed: http://www.stopandgo.org/gallery/trafficsigns/Emergency_plaque.html There's also an I-278 Truck in New York City that avoids a piece of the Grand Central Parkway that's closed to large trucks: http://www.openstreetmap.org/browse/relation/2131889 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/12/2012 3:52 PM, Nathan Edgars II wrote: There's also an I-278 Truck in New York City that avoids a piece of the Grand Central Parkway that's closed to large trucks: http://www.openstreetmap.org/browse/relation/2131889 Also I-270 Spur in Maryland, which *is* part of the Interstate Highway System and thus belongs in network=US:I: http://www.openstreetmap.org/browse/relation/1685926 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/11/2012 7:23 PM, Phil! Gold wrote: We're putting the shield images in the public domain (well, we're putting them under a CC0 waiver, which amounts to the same thing semantically), so I don't think the Kentucky Unbridled image would be compatible with that. You might have a problem with some other toll roads, depending on whether the designs pass the threshold of originality (and whether any signs were posted sans copyright notice before 1989). (You also would have had a problem with the Trans-Canada Highway if you were doing this 5 years ago, but Crown copyright on the logo expired in 2009 at the latest.) Normal state route shields should all be public domain per the MUTCD introduction. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tagging cul-de-sacs
On 4/10/2012 10:39 AM, Peter Dobratz wrote: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dturning_circle: There is no central island/reservation to a turning circle—it's simply a wider bit of road. There was a recent discussion on tagging@ in which the 'old guard' refused to accept that it may be common in some places to use turning_circle for a cul-de-sac with an island. Hence the wiki doesn't reflect reality. Another case is with a mini_roundabout - supposedly the center must be flat. But many small circles that fit inside intersections are tagged as mini_roundabouts even if they have a raised island. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tagging cul-de-sacs
On 4/10/2012 1:53 PM, Martijn van Exel wrote: On 4/10/2012 11:31 AM, Nathan Edgars II wrote: Another case is with a mini_roundabout - supposedly the center must be flat. But many small circles that fit inside intersections are tagged as mini_roundabouts even if they have a raised island. The wiki actually says 'there might be also a low, fully traversable dome'. Something like the examples in Mini-Roundabout Examples: Germany (Slide 10) on http://safety.fhwa.dot.gov/intersection/roundabouts/roundaboutsummit/rndabtatt5.htm And until recently it said that it *usually* does not have a physical island in the middle: http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dmini_roundaboutdiff=747981oldid=689543 I definitely consider this to be a mini_roundabout and continue to tag it as such: http://www.cityoforlando.net/transportation/TransportationEngineeringDiv/images/100_5738.JPG ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tagging cul-de-sacs
On 4/10/2012 2:23 PM, Paul Johnson wrote: If there's an island in the middle, create a circle around the island, set one-way in the direction of rotation (almost always anticlockwise in North America), intersect with outlet way, copy outlet's tags to the ring (think one-exit roundabout minus the junction=roundabout). That's only correct if there are signs saying it's one-way. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Updating of non-Mapnik map options
I've noticed that the only one of the four maps on the OSM main page that has been updating since April Fools has been the 'standard' Mapnik. ITO has also not updated their renderings due to an apparent lack of planet files. Does anyone have information about what's going on here? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] importing bus stops
On 4/10/2012 7:39 PM, Martijn van Exel wrote: I was planning to just use what I know which is highway=bus_stop for the bus stops, and railway=tram_stop for the light rail stops. But now I see that using highway=bus_stop is *very controversial*[1]! If it weren't so blatantly untrue I'd think it was a joke. Or did I miss something? [1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop I've removed this statement, which was added by a single user with no evidence, and does not seem to be true. http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dbus_stopdiff=592417oldid=592409 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Imagery parallax error in high altitude areas
On 4/1/2012 10:53 AM, Arun Ganesh wrote: It recently struck me while identifying mountain peaks in the himalayas that something may not be right. All of us have noticed that the top of skyscrapers is off from the base of the building owing to parallax error of the satellite capturing the image at an angle. The average seems to be around a 0.2m displacement for every 1m increase in height (based on calculations made in a couple of cities in India). For an imagery tile which has 1000m variation in elevation, various objects could be displaced by as much as 200m from its real position. It's not as bad as it seems. Imagery is adjusted using an elevation dataset. Since this data doesn't (and shouldn't) include buildings and bridges, these appear distorted. You'll also see problems where recent heavy construction has caused changes in topography. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Rendering of sidewalks
I'm wondering if anyone's created a rendering that takes sidewalk=* tags and places a line on the correct side(s) of the roadway. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Highway Shield Rendering
Is there a reason there are no shields or fallback ovals here on Nocatee Parkway? http://elrond.aperiodic.net/shields/?zoom=15lat=30.12344lon=-81.39063layers=B0 The way is tagged ref=CR 210 and the relation is network=US:FL:CR:St. Johns ref=210. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Imagery parallax error in high altitude areas
On 4/9/2012 11:01 PM, Russ Nelson wrote: Nathan Edgars II writes: It's not as bad as it seems. Imagery is adjusted using an elevation dataset. Since this data doesn't (and shouldn't) include buildings and bridges, these appear distorted. You'll also see problems where recent heavy construction has caused changes in topography. Or where the elevation dataset doesn't include a deep canyon, which causes a straight bridge to appear curved. If it's a railroad, you can be pretty sure it isn't. If it's a road bridge, you have to rely on what you saw when you were there. I think this is because the elevation data *does* include the canyon. Since the image was taken at an angle, the bridge appears at a different place in the canyon, and must curve to reach the correct location at the top. Here, for example: http://mapper.acme.com/?ll=38.06661,-81.08022z=16t=O The camera was to the northwest, so the bridge was on a line with the canyon southeast of its actual location. The bridge down in the bottom of the canyon is also curved, but much less so because it's smaller. It's also in essentially the correct place (as seen by comparing to Google's photos and USGS topos). (crossposted to talk-us because who knows when the talk@ mods will let this through) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
On 4/8/2012 10:27 AM, Craig Hinners wrote: Chris Lawrencelordsu...@gmail.com: modifier=* would represent MUTCD-type banners attached to the shield This is the first I've heard of this tag. I don't recall it being discussed when we were hashing ideas around on this last summer. (Not that that is reason to discount it.) But what came out of that discussion was the following guidance: ref will store the unique identifier within a particular classification, where particular classification is stored wholly in the network tag. So, network=US:US:Business/ref=13 and network=US:US:Truck/ref=70 both conform to that definition. network=US:US/modifier=Business/ref=13 does not. On the other hand, network=US:US ref=13 Business does. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
If you have any questions about real-world shields that aren't answered here, you can sign up for http://www.aaroads.com/forum/ and ask. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/5/2012 8:14 AM, Phil! Gold wrote: New York's parkways have a similar problem with legibility. One of my plans for dealing with them is to use larger shield images at high zoom levels. The Long Island parkways are nice and legible: http://alpsroads.net/roads/ny/ocean/e3.jpg Most other parkways use large initial caps in a green state route shield: http://alpsroads.net/roads/ny/sawmill/begin.jpg It should be reasonable to simply use the abbreviation horizontally, like the occasional (erroneous) sign: http://alpsroads.net/roads/ny/taconic/tsp.jpg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
I think it's clear from this discussion that we *don't* have any consensus on how best to tag relations for bannered routes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/2/2012 11:35 AM, Phil! Gold wrote: For things like Florida's toll roads, we currently treat that as a separate network, so a route relation tagged as network=US:FL:Toll, ref=528 would get the toll shield. I've done this: http://www.openstreetmap.org/browse/changeset/11177509 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/4/2012 11:49 AM, Phil! Gold wrote: * Nathan Edgars IInerou...@gmail.com [2012-04-04 10:41 -0400]: On 4/2/2012 11:35 AM, Phil! Gold wrote: For things like Florida's toll roads, we currently treat that as a separate network, so a route relation tagged as network=US:FL:Toll, ref=528 would get the toll shield. I've done this: http://www.openstreetmap.org/browse/changeset/11177509 The server's a bit overloaded at the moment, so already-rendered tiles might take a while to rerender and show the shields, but new renderings of not-yet-present tiles are given priority, so I was able to get some fresh tiles at zoom 15: http://elrond.aperiodic.net/shields/?zoom=15lat=28.4117lon=-80.82026layers=B0 Just noticed it in the Orlando area. Cheers. (By the way, if it wasn't clear, you've done some good work here.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
On 4/4/2012 12:14 PM, Craig Hinners wrote: Nathan Edgars IInerou...@gmail.com: It seems that many people see the network tag as not representing a network but a shield design. Does this sound accurate? No, because, where shield designs differ by agency for the same logical network classification, the network tag does not change, despite the differing shields. One of many examples: Maryland uses a unique green-on-white shield for US Business routes, but those roads still get tagged as network=US:US:Business, not network=US:US:Business:MD or somesuch. The renderer would have to detect which agency the road is in, and render the agency-specific shield accordingly. So your belief is that there is such a thing as a U.S. Highway Business network, despite AASHTO considering business routes to be part of the main U.S. Highway network? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
On 4/4/2012 1:05 PM, Richard Weait wrote: By analogy, you could map a business by placing a node: amenity=fuel. Or by tracing a building=yes, amenity=fuel. Same thing: you want a generic lozenge shield? ref=123 You want a right, clustered shield? network=US:US:Business:MD, ref=123 And you'd specify the type of fuel using a different tag, not amenity=fuel:diesel. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
On 4/4/2012 1:38 PM, Richard Weait wrote: On Wed, Apr 4, 2012 at 1:33 PM, Nathan Edgars IInerou...@gmail.com wrote: And you'd specify the type of fuel using a different tag, not amenity=fuel:diesel. name= would be a separate tag, so would fuel. Indeed. How this is a valid analogy for cramming non-network details into the network tag, I don't know. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
On 4/4/2012 2:43 PM, Chris Lawrence wrote: Renderers can fallback to the longest left-anchored substring they understand for weird things they don't understand. Bad idea. Google Maps does something like this and it results in 'bannered' routes appearing without banners. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
There seems to be a problem here with US 17-92: http://elrond.aperiodic.net/shields/?zoom=12lat=28.96029lon=-81.31906layers=B0 Change over to sign style and a bunch of shields appear. Example tiles (to avoid loading the whole thing): http://elrond.aperiodic.net/mtiles/cutouts/12/1122/1704.png http://elrond.aperiodic.net/mtiles/shields/12/1122/1704.png ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/4/2012 10:23 PM, Nathan Edgars II wrote: There seems to be a problem here with US 17-92: http://elrond.aperiodic.net/shields/?zoom=12lat=28.96029lon=-81.31906layers=B0 Change over to sign style and a bunch of shields appear. Example tiles (to avoid loading the whole thing): http://elrond.aperiodic.net/mtiles/cutouts/12/1122/1704.png http://elrond.aperiodic.net/mtiles/shields/12/1122/1704.png Er - upon rerendering, they don't appear in sign style anymore. That definitely says there's a problem now. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 10:21 AM, Chris Lawrence wrote: - Secondaries (network US:VA:secondary) don't seem to be rendering at all, and the fallback shields aren't showing up even where there are ref tags (just seems to be using Mapnik style). Simple rule for VA: if the ref= 600, or it has a letter in it, it's a secondary (except 785 and 895, which are signed primary). 1= 599 are primary. 785 isn't signed at all. The 895 near Richmond is primary, but there are also secondary 895s. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 10:54 AM, James Umbanhowar wrote: I don't know if they use Mapnik, but I like the way Stamen places their shields along concurrencies. e.g. http://maps.stamen.com/terrain/#15/39.7542/-86.0373 The problem with this one is that only one shield shows up when the two shields would be drawn on top of each other. Putting all the shields right next to each other avoids this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 11:19 AM, Phil! Gold wrote: A lot of those still don't render because they duplicate the subnetwork in the ref tag, so Loop 5 (picking an arbitrary number) might be represented as network=US:TX:LOOP, ref=5 Loop. Once the ref is changed to a plain 5, it would be rendered properly. You mean *if* the ref is changed. Perhaps the locals want to keep the Loop in the ref tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 11:57 AM, Paul Johnson wrote: FM and RM should render identically (obviously since they're actually the same network) Er no. On roadside assemblies the text FARM ROAD and RANCH ROAD appears, and on green guide signs the shields have FM or RM up top. http://onlinemanuals.txdot.gov/txdotmanuals/sfb/images/3-1_Types_Route_Sign_Mount.JPG ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 11:59 AM, Paul Johnson wrote: That just reminded me... Chicago and Tulsa have city routes. I'm not aware of any such routes in Chicago. Are you thinking of the address numbers that are prominently posted on signs? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 12:06 PM, Phil! Gold wrote: We're looking for US Business routes under a network of US:US:Business. It probably isn't tagged that way. Once it is, it'll show up. Again, you mean if, not once. It's not the job of renderers to force a choice between equally-valid existing tagging choices. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 12:52 PM, Phil! Gold wrote: * Nathan Edgars IInerou...@gmail.com [2012-04-03 11:44 -0400]: On 4/3/2012 11:19 AM, Phil! Gold wrote: A lot of those still don't render because they duplicate the subnetwork in the ref tag, so Loop 5 (picking an arbitrary number) might be represented as network=US:TX:LOOP, ref=5 Loop. Once the ref is changed to a plain 5, it would be rendered properly. You mean *if* the ref is changed. Perhaps the locals want to keep the Loop in the ref tag. Point taken. They will appear on our particular rendering if the locals choose to change the tagging. So you'll include network=US:US ref=17 Truck as acceptable tagging? Since I'm local to said route. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 5:19 PM, Phil! Gold wrote: If you want to tag your local routes that way, I won't stop you. But I don't want to have to deal with multiple tagging standards and it seems to me that there's a consensus on this list that network=US:US:Truck, ref=17 is the better approach, so that's what I will focus on rendering. That tagging is nonsense. There's no Truck U.S. Highway network, only a U.S. Highway network that includes truck-bannered routes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/3/2012 8:49 PM, Paul Johnson wrote: On Apr 3, 2012 3:15 PM, Nathan Edgars II nerou...@gmail.com mailto:nerou...@gmail.com wrote: That tagging is nonsense. There's no Truck U.S. Highway network, only a U.S. Highway network that includes truck-bannered routes. Correct me if I'm wrong, but aren't bannered routes pretty much the reason for the modifier tag? Yes, they are, and I would not object to ref=17 modifier=Truck, except that you run into problems with an alternate route that's signed with a suffix - ref=70A with no modifier doesn't include the information that it's a modified version of another route, and ref=70 modifier=A would be unclear as to how the A modifies the 70 (it could be 70-A). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/2/2012 8:25 AM, Phil! Gold wrote: Business and similar variants are expected to be in the network tag, since that's the closest thing I've seen to a consensus on the topic. If there's no route relation or the tagging was not understood, we fall back to rendering the ref= tag on the way just like the main OSM rendering. You know that MapQuest's rendering expects the ref tag to contain the modifier, right? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/2/2012 8:25 AM, Phil! Gold wrote: I'm not an expert on every state, so I'm particularly interested in whether things look good to the natives of each state and, if not, what could make them look better. Florida has special toll shields. These are not represented by relations since, for example, SR 528 is partly toll-shielded and partly normal shielded. If the ref tag on the way is 528 Toll rather than 528, it gets a toll shield. Example: http://www.openstreetmap.org/?lat=28.4112lon=-80.8121zoom=13layers=Q http://www.okroads.com/121603/i95flexit205.JPG ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/2/2012 11:17 AM, Phil! Gold wrote: * Nathan Edgars IInerou...@gmail.com [2012-04-02 09:18 -0400]: On 4/2/2012 8:25 AM, Phil! Gold wrote: Business and similar variants are expected to be in the network tag, since that's the closest thing I've seen to a consensus on the topic. You know that MapQuest's rendering expects the ref tag to contain the modifier, right? As far as I can tell, MapQuest is basing their rendering entirely on the ref= tag on ways. Yes, as far as I know. But since the modifier appears after the number (US 1 Alternate) it's clearly part of the 'ref' part of the ref rather than the network. Doing something different on relations will only confuse people. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On 4/2/2012 11:40 AM, Nathan Edgars II wrote: On 4/2/2012 11:17 AM, Phil! Gold wrote: * Nathan Edgars IInerou...@gmail.com [2012-04-02 09:18 -0400]: On 4/2/2012 8:25 AM, Phil! Gold wrote: Business and similar variants are expected to be in the network tag, since that's the closest thing I've seen to a consensus on the topic. You know that MapQuest's rendering expects the ref tag to contain the modifier, right? As far as I can tell, MapQuest is basing their rendering entirely on the ref= tag on ways. Yes, as far as I know. But since the modifier appears after the number (US 1 Alternate) it's clearly part of the 'ref' part of the ref rather than the network. Doing something different on relations will only confuse people. Actually, is there a reason it can't support both? (This sort of flexibility could also be used, for example, when an Interstate relation has the I in the ref, such as most of I-80, and to process any network=US:FL:CR:* as a county road.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addition of building footprints in selected U.S. and Canadian cities
On 4/2/2012 12:18 PM, Richard Weait wrote: I think imports (taking a large number of objects from an external source and placing them in OSM all at once) is bad for the community. Most of you have heard me say this before. I still have no hard evidence to prove it. There is also no hard counter-evidence. At best, imported data will be unmaintained. I glibly offer most TIGER ways as evidence. I offer TIGER as counterevidence. It's imperfect but a great starting point for local mappers, especially those without a GPS setup. No comment on the proposed import. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
