[Talk-us] Highway Shield Rendering
Here's something that might be a diversion while you wait for the database to allow editing again. Richard Weait and I have been working on a rendering that uses route relations to make individual shields that reflect what each state uses. I've got a working prototype, and I'd like to get some feedback on it. The server is a rather slow one sitting at my place behind a slow-ish DSL connection, which means that it'll probably range from a little slow to very slow indeed. I'm working on getting some better hosting for it. If you're not yet deterred, I invite you to look at http://elrond.aperiodic.net/shields/ . The code and source files are at https://launchpad.net/osm-shields . I haven't yet written up the details about what works or doesn't but the basic gist is that we use the network= and ref= tags on the relation and, if there's no ref= tag, use the name= tag so we can get things like the New Jersey Turnpike, which has a name but no signed number. 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. There are actually two shield styles we have. There's the cutout-style that you see by default and another style you can switch to that more closely resembles the roadside reassurance signs for the routes. The cutouts will probably load faster--more of them have been rendered already--but please take a look at the other one, too; I'd like to know which one people prefer. 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. If you just want to look around, here are some spots you might find interesting: * The greatest concurrency in the US is an 8-plex in Indiana: http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0 * New Jersey has several highways with their own shields. You can see both the New Jersey Turnpike and the Garden State Parkway here: http://elrond.aperiodic.net/shields/?zoom=12lat=40.53314lon=-74.31054layers=B0 * Many states have boring rectangles for their shields. Some have interesting shields with details that don't really come out with our rendering. Two of the more visually interesting states that we do show are, I think, Washington and Utah: http://elrond.aperiodic.net/shields/?zoom=12lat=40.53314lon=-74.31054layers=B0 http://elrond.aperiodic.net/shields/?zoom=11lat=40.6916lon=-111.90163layers=B0 * Even Washington DC has its own shield design, but there's only one road with that sign, DC 295 (which is a connector between MD 295 and I-295): http://elrond.aperiodic.net/shields/?zoom=14lat=38.88345lon=-76.9615layers=B0 So be patient with it if the tiles load slowly and please let me know what you think! -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- ...And the lord said, 'lo, there shall only be case or default labels inside a switch statement.' -- Apple MPW C Compiler error message --- -- ___ 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 Mon, Apr 2, 2012 at 9:18 AM, Nathan Edgars II nerou...@gmail.com wrote: 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? When eating chicken wings, the pseudonym known as NE2 complains about the bones, rather than enjoying the meat. :-) ___ 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: Richard Weait and I have been working on a rendering that uses route relations to make individual shields that reflect what each state uses. Superb! This will greatly assist OSM to make inroads in the US - for those who glance at the map, see the weird ovals, and dismiss it as a child's toy. I looked at some of the states that I know about, and they look great to me.In SC, I haven't bothered with route relations yet - I see that it will now be project ONE after the great license purge of 2012 is complete! (NE2 has created several in SC: http://elrond.aperiodic.net/shields/?zoom=16lat=33.80378lon=-78.79053layers=B0 ) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
Indianapolis has some crazy multiplexes. Look here to see properly tagged 5-, 6- and 7-plexes rendered correctly and beautifully. http://elrond.aperiodic.net/shields/?zoom=12lat=39.7007lon=-86.09646layers=B0 Phil, you were absolutely right about using the cutout style shields on the US route markers. They look great. ___ 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: please let me know what you think! Looks great - does the US OSMF have server(s) that can host this style yet? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On Mon, Apr 2, 2012 at 10:26 AM, Mike N nice...@att.net wrote: On 4/2/2012 8:25 AM, Phil! Gold wrote: please let me know what you think! Looks great - does the US OSMF have server(s) that can host this style yet? As far as I know: Does the US Local Chapter have a server? - Yes. Can it host and serve tile sets? - Yes. Of this type? - Perhaps. Will they serve this style? - Up to them. :-) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
On Mon, Apr 2, 2012 at 9:26 AM, Mike N nice...@att.net wrote: On 4/2/2012 8:25 AM, Phil! Gold wrote: please let me know what you think! Looks great - does the US OSMF have server(s) that can host this style yet? OSM US has a server and I told Phil and Richard that I'd work on getting the tiles going. I was going to work on it this past weekend but got busier than I thought. It seems like it should be pretty quick to get going, though. I'll let them know when it's running so they can announce more general use. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@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. That's certainly what their stylesheets at https://github.com/MapQuest/MapQuest-Mapnik-Style do; those don't look at route relations at all. I can't be completely authoritative on this, since those stylesheets don't appear to have any cases for rendering business shields, so they're probably out of date with respect to the current MapQuest rendering. It seems likely, however, that they're still extracting their data from the ways' ref= tags, so our rendering is in a different category. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I just had a bad day. Well, join the club. Can I be president? I'm president. You can be the janitor. -- Buffy and Dawn (Buffy the Vampire Slayer, No Place Like Home) --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-02 09:23 -0400]: 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. There's a similar problem in Tennessee, where a route may go back and forth between primary and secondary signage depending on the state's classification of the road at that point. For the moment, we opted to ignore the Tennessee problem as much as possible and use the primary sign for a route if any part of that route is signed as a primary. 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 can see the argument that the toll portions are still considered part of SR 528 so they should still be part of the SR 528 route relation, but there is something distinct about them, since they are signed differently. Making a separate relation for the toll portions and putting the tolled ways into both relations might not be a bad solution. That's definitely one that I, as a data consumer, could handle. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- If the code and the comments disagree, then both are probably wrong. -- Norm Schryer --- -- ___ 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
So here's something to mull over while we all wait for the license upgrade: http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris -- William Morris Cartographer (802)-870-0880 wboyk...@geosprocket.com Twitter: @vtcraghead GeoSprocket LLC, Burlington VT www.geosprocket.com On Thu, Mar 22, 2012 at 9:35 PM, William Morris wboyk...@geosprocket.com wrote: Ian, Honestly - and with a certain amount of shame - I had planned to just pull both sets of buildings into ArcMap and run location SQL (select from UVM-SAL buildings where intersect with OSM buildings), then invert the selection and export. It seemed like this approach is conservative toward OSM feature preservation and might also be good for QA/QC in small batches. Unfortunately I'm noticing that the cloudmade shapefile zips don't include buildings. Moving on to the next idea . . . Josh, I would happily assist on the plugin if I knew the first thing about Java. I'm more inclined to lean on GDAL/OGR in the backend, but I agree it would be fantastic to have this functionality in the editors. -B On Thursday, March 22, 2012, Josh Doe j...@joshdoe.com wrote: On Thu, Mar 22, 2012 at 4:23 PM, Ian Dees ian.d...@gmail.com wrote: Personally, I'm most interested in discovering how you're planning on doing the conflict detection between the incoming data and existing OSM data. The import list has been interested in something like that for a long time and we haven't really had something that did it right. Sounds like this could be a good application of the conflation plugin I've been working on. I'm in the process of integrating the Java Topology Suite (JTS) and the Java Conflation Suite (JCS) which offers some pretty powerful matching features based on attributes (tags), distance, overlap, etc. Like others have said, this would still need to be done at a local level in small chunks, which is good since the plugin likely can't handle matching more than 5000 or so objects without taking forever. I'd be glad to have help on the plugin however, my nights and weekends have been pretty busy lately... -Josh ___ 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 Mon, Apr 2, 2012 at 11:46 AM, William Morris wboyk...@geosprocket.com wrote: So here's something to mull over while we all wait for the license upgrade: http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris My objection is a generic one and one that has been heard before on this channel. To be clear, I do not wish to criticise Bill; he appears to be following the bulk edit guidelines and he is engaging in the discussions here. That's fantastic. Bill, welcome to the community. 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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. Can we try something new? Can we use this building data as motivation to get new mappers in those areas so that specific mappers will have a stronger connection to the data in specific areas? Something like this: - Let's set a smaller grid. Something like a large suburban arterial block, say 1.5km / 1 mi square. - If you want to import the buildings in one grid square, you have to find a new mapper in that area, and they have to do an on the ground survey of some part of that area. - You can only do so in areas that are no more than four grid squares from your home location (or work location). This is a cross between adding game-features to OSM, banning imports and having users adopt part of the map. :-) This could be really beneficial to a new mapper. They could survey the local fire station, police station, hospital and schools, and perhaps the businesses on the main street, and a few local shopping malls. They get all of those business names, and they'll be completely up to date. They'll add them to the map, and they don't have to trace as many building outlines, because they have the external source available. What I hope this will encourage is: - new mappers in those areas - who will do new foot surveys of interesting things - and will feel attached to the data - and keep it up to date over time. And, if the new mapper understands that the building data for their area is a reward, they are unlikely to be frustrated or discouraged by it if some buildings end up in the wrong place. the new mapper will just fix them. And carry on mapping. I know that what I suggest is much harder than simply importing the data from one or two accounts. I suggest that the benefit of finding and encouraging new mappers in your area is much greater than just having new building outlines in your area. Now the Negative Army will jump in and say, That's too hard., That will never work., I want buildings now. You can take leadership on this. Are you the only active mapper in your city or region, or one of only a few? Do this. Be a leader. Grow the community and then you won't be able to keep up with the growth of the map. Build new contributors. (And host local OSM groups.) Thanks for letting me hijack your thread, Bill. :-) Best regards, Richard. ___ 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
Re: [Talk-us] Highway Shield Rendering
Phil! this looks pretty good for what I think you are saying is an early version of these renderings. I was a bit surprised to see shields beginning to render only at zoom level 11, and spottily at that. Shields at zoom levels 10, 9 and even 8 and 7 (maybe Interstates only?) would be helpful, if crowded in spots. I realize that perhaps 11 as a starting point is only just that. Yes, 12, 13 and up to 14 work, but 15 and above just display pink tiles. You likely know that already, and I supposed that is to reduce tile server load; OK. Most specific shields in California look good and familiar, as you make correct distinctions between Interstates and state routes. However, county routes (designated by a regional letter and a number, such as S 21) are not rendered with proper shields at all. This is a critical component for many areas. And oddly, in the San Diego area, CA 209 and CA 75 (Point Loma and Coronado, respectively) don't render with your newer shields, but the old style Mapnik shields. Even in read only mode I am unable coax JOSM to read only so I can't see what these (S 21, CA 209 and CA 75) tags are. It may be that they are tagged in a wrong or odd way, it may be that you aren't catching a certain case of things, I'm not sure. Also, there are some toll ways in Orange County (California, e.g. CA 73, CA 241) which don't render specifically as toll, but as there is no distinct shield in California to distinguish toll roads, I'm not sure this is a defect in your algorithm or renderings -- the regular state route shield is displayed, apparently correctly. I also see absolutely no business routes where I know them to exist. I'm still searching for some in your rendering, but haven't found any (yet). That's my first look at your first cut. At least your first public cut as broadcast to the talk-us pages. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* stevea stevea...@softworkers.com [2012-04-02 10:55 -0700]: I was a bit surprised to see shields beginning to render only at zoom level 11, and spottily at that. Shields at zoom levels 10, 9 and even 8 and 7 (maybe Interstates only?) would be helpful, if crowded in spots. Shields are supposed to start rendering at zoom 10, but they're not. This is a bug. What the rendering should be is: motorway shields at zoom 10, plus trunk and primary at zoom 11, plus secondary at zoom 12, plus everything else at zoom 13. I'm working on just doing Interstates (and the Trans-Canada Highway, pending some discussion about how to properly tag it on talk-ca@) starting at zoom 7, but that's not in the tiled rendering yet. Yes, 12, 13 and up to 14 work, but 15 and above just display pink tiles. It depends on where you are looking. If you're getting a lot of pink tiles, that's probably because they haven't been rendered yet and the server is taking too long to render them, so your requests are timing out. There should be an error tile suggesting that you wait a bit and try back later, but that doesn't always load properly. Everything up to zoom 12 is prerendered. Zooms 13 and 14 can be slow to render, but 15 and up normally go quickly except in dense urban areas. Most specific shields in California look good and familiar, as you make correct distinctions between Interstates and state routes. However, county routes (designated by a regional letter and a number, such as S 21) are not rendered with proper shields at all. This is a critical component for many areas. I'm deliberately leaving county routes for a second phase and focusing on state routes for the moment. (New Jersey is an exception, but it was an experiment and I don't actually believe we're using the proper shields for all of its counties.) And oddly, in the San Diego area, CA 209 and CA 75 (Point Loma and Coronado, respectively) don't render with your newer shields, but the old style Mapnik shields. It looks like there aren't route relations for those routes yet, so the rendering falls back to the old shield style for them. Also, there are some toll ways in Orange County (California, e.g. CA 73, CA 241) which don't render specifically as toll, but as there is no distinct shield in California to distinguish toll roads, I'm not sure this is a defect in your algorithm or renderings -- the regular state route shield is displayed, apparently correctly. Do toll roads get any difference in signage, like a banner above or below the shield? If so, then we just need to make images that match and get routes that identify them. (Right now that would probably be with a network of US:CA:Toll, but see NE2's and my emails about Florida toll roads.) I also see absolutely no business routes where I know them to exist. I'm still searching for some in your rendering, but haven't found any (yet). They might not show up. Based on previous discussions on this list, we've chosen to look for the business designation (as well as others) in the network tag on the route relation. A lot of relations have the route modifier in the ref tag, though (so they might be network=US:US, ref=5 Business instead of network=US:US:Business, ref=5), so they don't get rendered at the moment. (And on top of that, there are slightly different signs for spur and loop business Interstates, so I ended up looking for networks like US:I:Business:Loop and US:I:Downtown:Spur even though no one's actually doing that yet.) There are some business routes that our rendering understands here: http://elrond.aperiodic.net/shields/?zoom=12lat=38.36793lon=-75.59339layers=B0 -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Plumber mistook routing panel for decorative wall fixture. -- BOFH excuse #55 --- -- ___ 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 2:27 PM, Phil! Gold wrote: I'm deliberately leaving county routes for a second phase and focusing on state routes for the moment. (New Jersey is an exception, but it was an experiment and I don't actually believe we're using the proper shields for all of its counties.) As far as I know, all New Jersey counties use the pentagon for 500-series routes. All but Bergen and sometimes Camden use it for others (though the occasional old sign still exists). You can see both types here: http://alpsroads.net/roads/nj/cr_502/ They might not show up. Based on previous discussions on this list, we've chosen to look for the business designation (as well as others) in the network tag on the route relation. A lot of relations have the route modifier in the ref tag, though (so they might be network=US:US, ref=5 Business instead of network=US:US:Business, ref=5), so they don't get rendered at the moment. A total of *two* relations have network=US:US:Business, vs. 707 with network=US:US and modifier=Business. Yes, I know I had major influence in that, but that was months ago. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addition of building footprints in selected
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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. While imports are bad for mappers, disallowing imports is also bad for users. We had initially had a lot of enthusiasm for OSM and were planning to integrate it into our editing workflows and applications. When imports from our editing workflow were rejected, we pretty much gave up. Our cartographer group hand edits just as much as a volunteer mapper, including fieldwork, official documents, lidar, and aerial photography in their workflow. We even have terabytes of GPS traces from our patrol vehicles. When their contributions were disallowed, we were essentially cut off from making any corrections to data that we knew was wrong. That greatly decreased the value of OSM for us, and we stopped plans to use OSM for new web applications. Obviously we completely halted plans to integrate it into our editing workflows. So yes, this strategy encourages new mappers, but having to stare at bad data without being able to touch it also discourages us as a new user. I suspect we are not the only group discouraged in this way. Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addition of building footprints in selected
There was initial enthusiasm from some folks I've talked to at the NYPD Office of Emergency Management. They're unfortunately hindered more by NYC's ill-suited data policy but the fact remains that they have far better data than sets like Tiger and get discouraged seeing folks manually redoing the work they do all day long. (note: not official word of NYC or OEM, but the feeling I've gathered in talking with one of their GIS honchos) On Apr 2, 2012 4:15 PM, Brett Lord-Casitllo marigol...@yahoo.com 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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. While imports are bad for mappers, disallowing imports is also bad for users. We had initially had a lot of enthusiasm for OSM and were planning to integrate it into our editing workflows and applications. When imports from our editing workflow were rejected, we pretty much gave up. Our cartographer group hand edits just as much as a volunteer mapper, including fieldwork, official documents, lidar, and aerial photography in their workflow. We even have terabytes of GPS traces from our patrol vehicles. When their contributions were disallowed, we were essentially cut off from making any corrections to data that we knew was wrong. That greatly decreased the value of OSM for us, and we stopped plans to use OSM for new web applications. Obviously we completely halted plans to integrate it into our editing workflows. So yes, this strategy encourages new mappers, but having to stare at bad data without being able to touch it also discourages us as a new user. I suspect we are not the only group discouraged in this way. Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400Fax: 314-628-5508 Direct: 314-628-5407 ___ 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] Addition of building footprints in selected U.S. and Canadian cities
On 4/2/2012 12:06 PM, Nathan Edgars II wrote: I offer TIGER as counterevidence. It's imperfect but a great starting point for local mappers, especially those without a GPS setup. This is definitely true for those of us in areas with few mappers. OSM would be largely useless here without the TIGER import. Not completely, mind you, but it's not much good if it's only got Interstates and US highways. -Nathan ___ 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 Mon, Apr 2, 2012 at 4:25 PM, Nathan Mills nat...@nwacg.net wrote: On 4/2/2012 12:06 PM, Nathan Edgars II wrote: I offer TIGER as counterevidence. It's imperfect but a great starting point for local mappers, especially those without a GPS setup. This is definitely true for those of us in areas with few mappers. For some of you. I've had conversations with approximately equal numbers of mappers who feel as you do, and potential mappers who look at TIGER and say, Finished. Nothing for me to do. And there are those who arrive and look at TIGER and say, I have to start by fixing that mess? No thanks. ___ 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 Mon, Apr 2, 2012 at 3:32 PM, Richard Weait rich...@weait.com wrote: On Mon, Apr 2, 2012 at 4:25 PM, Nathan Mills nat...@nwacg.net wrote: On 4/2/2012 12:06 PM, Nathan Edgars II wrote: I offer TIGER as counterevidence. It's imperfect but a great starting point for local mappers, especially those without a GPS setup. This is definitely true for those of us in areas with few mappers. For some of you. I've had conversations with approximately equal numbers of mappers who feel as you do, and potential mappers who look at TIGER and say, Finished. Nothing for me to do. And there are those who arrive and look at TIGER and say, I have to start by fixing that mess? No thanks. Then OSM is doing a bad job at messaging. It's no longer just a road network project, it's a map project. We should show that there's other data to add beyond a semi-complete TIGER import. If you show a new person openstreetmap.org and they say to you done! and move on, then you should ask them if their house, their school, their zoo, their supermarket, etc. are on the map and to add them if they're not. If you're not there, then we should think about how to have the website ask for you. Let's stop blaming people trying to improve the map by adding data in the right way and start looking at ways to help those that are distracted by all that data. ___ 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
Hi Bill, This location ( http://www.openstreetmap.org/?lat=41.29693lon=-75.87369zoom=17layers=M) has a number of hand editing building outlines. If the data you're looking at is reasonably close in quality to this area then I think we should discuss going ahead with the addition of your outlines. Best, On Mon, Apr 2, 2012 at 11:46 AM, William Morris wboyk...@geosprocket.comwrote: So here's something to mull over while we all wait for the license upgrade: -- John Novak Novacell Technologies and the Old Topo Depot http://www.novacell.com 585-OLD-TOPOS (585-653-8676) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remapping is good
At 2012-01-31 13:52, Nick Hocking wrote: This morning I decided to remap another street off Cypress Avenue L.A. I randomly choose Ariva Street and lo and behold the TIGER2011 overlay said that it was Arvia Street. TIGER is usually spot on with names and since a Bing search and Google maps/street view also agree about Arvia this street is now correctly named (courtesy of TIGER). Sorry I missed this earlier... 1. I've researched many hundreds of naming issues in southern Cal. I can't give you a specific percentage, but neither TIGER05 nor TIGER11 could be considered usually spot on, nor could most other sources. 2. AFAIK, you cannot use Google Maps/Earth as a source for naming, due to licensing. Same applies to Bing Maps, though we are specifically allowed use of their satellite imagery. Using them, anyway, would just be repeating an unknown source - not necessarily conducive to better map quality. 3. For LA County, there are great online sources of public records: 3a. Tract Maps: http://gis.dpw.lacounty.gov/website/SurveyRecord/tractMain.cfm and http://gis.dpw.lacounty.gov/landrecords/index.cfm?docType=TM and parcel maps: http://gis.dpw.lacounty.gov/website/SurveyRecord/parcelMain.cfm and http://gis.dpw.lacounty.gov/landrecords/index.cfm?docType=PM . These are official and should generally be given the most weight, particularly newer ones. Tract maps are preferable to parcel maps Streets that surround the subject tract or parcel will occasionally have mistakes in them. I tag objects based on these with source=LACDPW + source_ref=TR-ppp or MB-ppp for tract maps, or PMbbb-ppp for parcel maps. 3b. Assessor's maps: http://maps.assessor.lacounty.gov/mapping/viewer.asp Note that the basemap used in the viewer is not necessarily accurate, as it's sourced from a different place than the official assessor's maps. Find a property parcel along the street you want and use the (i)nfo tool to select it. Then, click on the Click here to view Assessor's Map, which will open a PDF map http://maps.assessor.lacounty.gov/mapping/viewAssessorMapPDF.asp?val=-ppp where is the 0-padded book number and ppp is the 0-padded page number (there are some exceptions to this format for very old areas). I tag objects based on these with source=LACA + source_ref=ABK-ppp or AM-ppp. 3c. You can check a parcel address against the USPS address database here: https://tools.usps.com/go/ZipLookupAction!input.action (not sure about legality here - it's arguable). 3d. Photo survey. A good old local observation of the street sign(s), hopefully with photo evidence can be helpful. I tag these source=survey;image + source_ref=AM909_DSCx (my picture number). Do note, though, that these are sometimes wrong (particularly street type). However, they at least warrant an alt_name tag until they are corrected. When I find incorrect signs, I generally research the responsible authority (incorporated city or county) and tell them about it. There are often instances where you have to decide which is correct, or you can't, in which case you should add an alt_name tag, all your source tags (semi-colon separated), and a note tag to explain the research done. Don't forget to remove the tiger:reviewed tag from ways you verify or edit, too. If people are going to spend an entire night armchair mapping, wouldn't it be great if they all remapped L.A. Maybe. As always, please look at the existing description, note, source and source_ref tags and/or history to see previous edits. It's not nice to incorrectly armchair-edit an object that someone else spent some time researching. Ways with tiger:reviewed tags (highlighted in various editors) are a good start, as they have usually not been edited. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
For areas in New Jersey, when I look at this rendering, I get county shields for all 500-series roads, but no shields are shown for 600-series roads anywhere. http://elrond.aperiodic.net/shields/?zoom=15lat=39.36147lon=-74.55092layers=B0 This is an example of this problem. The formatting for county route relations in New Jersey is 'network=US:NJ:[county name]' for all county routes that are not part of the statewide system (for which 'network=US:NJ:CR' is used). -- View this message in context: http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5613933.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Addition of building footprints in selected U.S. and Canadian cities
We did an imperfect import of building footprints in Washington D.C. a while ago. I personally find it makes the map far more usable for adding other information. With the buildings in I am able to add stores and other details easily without using a GPS, simply by printing Walking Papers. Personally for me I enjoy outlining buildings, but there are plenty of other places without footprints where I could do that if I had the urge. -Kate On Mon, Apr 2, 2012 at 9:18 AM, Richard Weait rich...@weait.com wrote: On Mon, Apr 2, 2012 at 11:46 AM, William Morris wboyk...@geosprocket.com wrote: So here's something to mull over while we all wait for the license upgrade: http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris My objection is a generic one and one that has been heard before on this channel. To be clear, I do not wish to criticise Bill; he appears to be following the bulk edit guidelines and he is engaging in the discussions here. That's fantastic. Bill, welcome to the community. 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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. Can we try something new? Can we use this building data as motivation to get new mappers in those areas so that specific mappers will have a stronger connection to the data in specific areas? Something like this: - Let's set a smaller grid. Something like a large suburban arterial block, say 1.5km / 1 mi square. - If you want to import the buildings in one grid square, you have to find a new mapper in that area, and they have to do an on the ground survey of some part of that area. - You can only do so in areas that are no more than four grid squares from your home location (or work location). This is a cross between adding game-features to OSM, banning imports and having users adopt part of the map. :-) This could be really beneficial to a new mapper. They could survey the local fire station, police station, hospital and schools, and perhaps the businesses on the main street, and a few local shopping malls. They get all of those business names, and they'll be completely up to date. They'll add them to the map, and they don't have to trace as many building outlines, because they have the external source available. What I hope this will encourage is: - new mappers in those areas - who will do new foot surveys of interesting things - and will feel attached to the data - and keep it up to date over time. And, if the new mapper understands that the building data for their area is a reward, they are unlikely to be frustrated or discouraged by it if some buildings end up in the wrong place. the new mapper will just fix them. And carry on mapping. I know that what I suggest is much harder than simply importing the data from one or two accounts. I suggest that the benefit of finding and encouraging new mappers in your area is much greater than just having new building outlines in your area. Now the Negative Army will jump in and say, That's too hard., That will never work., I want buildings now. You can take leadership on this. Are you the only active mapper in your city or region, or one of only a few? Do this. Be a leader. Grow the community and then you won't be able to keep up with the growth of the map. Build new contributors. (And host local OSM groups.) Thanks for letting me hijack your thread, Bill. :-) Best regards, Richard. ___ Imports mailing list impo...@openstreetmap.org
Re: [Talk-us] Remapping is good
At 2012-02-01 06:08, Nick Hocking wrote: Ok I've found a few more close typos Gassen not Glassen Correct. source=LACDPW;LACA + source_ref=PWFB1521-265;TR0044-020;ABK5456-016 Tropico not Tropica Correct. Tropico Way in LA 90065: source=LACDPW;LACA + source_ref=TR0726-039;ABK5464-006 Tropico Ave in Whittier: source=LACDPW;LACA + source_ref=TR0518-006;ABK8228-010 Lavell not lavel Correct. source=LACDPW;LACA + source_ref=PWFB1521-257;TR0023-102a;ABK5462-006 Pleasant View not Pleasent View Correct. source=LACDPW;LACA + source_ref=TR0012-064;ABK5454-023 Seymour not Seymore This one was interesting. See the notes at the bottom of the tract map for the name changes - the previous name was, in fact, Seymore. Name changes aren't always noted on these docs, so it's important to look at the dates, but it's nice when they are. source=LACDPW;LACA + source_ref=TR0016-042b;ABK5453-019 Arroyo Seco not Aroyo Seco Correct. source=LACDPW;LACA + source_ref=TR0049-071;ABK5446-022 Parrish not Parish It depends: In LA 90065, Parrish Ave: source=LACDPW;LACA + source_ref=PWFB1521-257;TR0101-001;ABK5462-008 In Burbank, Parish Pl: source=LACDPW;LACA + source_ref=PWFB1718-924;TR0128-041;ABK2444-009 Shilburn not Shelburn In LA 90065, Shelburn Ct is correct. source=LACDPW;LACA + source_ref=PWFB1422-333;TR0022-115b;ABK5451-008 Shelburne is used in two other places. I've have not fixed the Parrish/Lavell ones since there is something really wrong with either or both of OSM and TIGER. I believe that this area really needs another survey. I do have an unprocessed photo survey of the area I did in January and August 2010. Maybe if we ever get past the license change fixes... It would be great if TIGER2011 could be in one half of Frederik's compare tool and OSM in the other, however putting Google in the other half allows you to easily spot where there are potential spelling mistakes in the OSM data. In small areas, I've generated a unique list of names from an OSM file and then from TIGER or some county source and done a diff to identify the obvious ones. Of course, you have to re-abbreviate the OSM street types, and do various other manual things, but it's better than a visual compare. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Addition of building footprints in selected U.S. and Canadian cities
Kate, What was the source for the building footprint import ? On Mon, Apr 2, 2012 at 6:58 PM, Kate Chapman k...@maploser.com wrote: We did an imperfect import of building footprints in Washington D.C. a while ago. I personally find it makes the map far more usable for adding other information. With the buildings in I am able to add stores and other details easily without using a GPS, simply by printing Walking Papers. Personally for me I enjoy outlining buildings, but there are plenty of other places without footprints where I could do that if I had the urge. -Kate On Mon, Apr 2, 2012 at 9:18 AM, Richard Weait rich...@weait.com wrote: On Mon, Apr 2, 2012 at 11:46 AM, William Morris wboyk...@geosprocket.com wrote: So here's something to mull over while we all wait for the license upgrade: http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris My objection is a generic one and one that has been heard before on this channel. To be clear, I do not wish to criticise Bill; he appears to be following the bulk edit guidelines and he is engaging in the discussions here. That's fantastic. Bill, welcome to the community. 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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. Can we try something new? Can we use this building data as motivation to get new mappers in those areas so that specific mappers will have a stronger connection to the data in specific areas? Something like this: - Let's set a smaller grid. Something like a large suburban arterial block, say 1.5km / 1 mi square. - If you want to import the buildings in one grid square, you have to find a new mapper in that area, and they have to do an on the ground survey of some part of that area. - You can only do so in areas that are no more than four grid squares from your home location (or work location). This is a cross between adding game-features to OSM, banning imports and having users adopt part of the map. :-) This could be really beneficial to a new mapper. They could survey the local fire station, police station, hospital and schools, and perhaps the businesses on the main street, and a few local shopping malls. They get all of those business names, and they'll be completely up to date. They'll add them to the map, and they don't have to trace as many building outlines, because they have the external source available. What I hope this will encourage is: - new mappers in those areas - who will do new foot surveys of interesting things - and will feel attached to the data - and keep it up to date over time. And, if the new mapper understands that the building data for their area is a reward, they are unlikely to be frustrated or discouraged by it if some buildings end up in the wrong place. the new mapper will just fix them. And carry on mapping. I know that what I suggest is much harder than simply importing the data from one or two accounts. I suggest that the benefit of finding and encouraging new mappers in your area is much greater than just having new building outlines in your area. Now the Negative Army will jump in and say, That's too hard., That will never work., I want buildings now. You can take leadership on this. Are you the only active mapper in your city or region, or one of only a few? Do this. Be a leader. Grow the community and then you won't be able to keep up with the growth of the map. Build new contributors. (And
Re: [Talk-us] [Imports] Addition of building footprints in selected U.S. and Canadian cities
DC GIS http://wiki.openstreetmap.org/wiki/Import/Catalogue -Kate On Mon, Apr 2, 2012 at 5:56 PM, the Old Topo Depot oldto...@novacell.com wrote: Kate, What was the source for the building footprint import ? On Mon, Apr 2, 2012 at 6:58 PM, Kate Chapman k...@maploser.com wrote: We did an imperfect import of building footprints in Washington D.C. a while ago. I personally find it makes the map far more usable for adding other information. With the buildings in I am able to add stores and other details easily without using a GPS, simply by printing Walking Papers. Personally for me I enjoy outlining buildings, but there are plenty of other places without footprints where I could do that if I had the urge. -Kate On Mon, Apr 2, 2012 at 9:18 AM, Richard Weait rich...@weait.com wrote: On Mon, Apr 2, 2012 at 11:46 AM, William Morris wboyk...@geosprocket.com wrote: So here's something to mull over while we all wait for the license upgrade: http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris My objection is a generic one and one that has been heard before on this channel. To be clear, I do not wish to criticise Bill; he appears to be following the bulk edit guidelines and he is engaging in the discussions here. That's fantastic. Bill, welcome to the community. 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 ask you to suspend disbelief for a moment, and presume that imports are generally bad, and presume that adding new mappers is generally good. Can we try something new? Can we use this building data as motivation to get new mappers in those areas so that specific mappers will have a stronger connection to the data in specific areas? Something like this: - Let's set a smaller grid. Something like a large suburban arterial block, say 1.5km / 1 mi square. - If you want to import the buildings in one grid square, you have to find a new mapper in that area, and they have to do an on the ground survey of some part of that area. - You can only do so in areas that are no more than four grid squares from your home location (or work location). This is a cross between adding game-features to OSM, banning imports and having users adopt part of the map. :-) This could be really beneficial to a new mapper. They could survey the local fire station, police station, hospital and schools, and perhaps the businesses on the main street, and a few local shopping malls. They get all of those business names, and they'll be completely up to date. They'll add them to the map, and they don't have to trace as many building outlines, because they have the external source available. What I hope this will encourage is: - new mappers in those areas - who will do new foot surveys of interesting things - and will feel attached to the data - and keep it up to date over time. And, if the new mapper understands that the building data for their area is a reward, they are unlikely to be frustrated or discouraged by it if some buildings end up in the wrong place. the new mapper will just fix them. And carry on mapping. I know that what I suggest is much harder than simply importing the data from one or two accounts. I suggest that the benefit of finding and encouraging new mappers in your area is much greater than just having new building outlines in your area. Now the Negative Army will jump in and say, That's too hard., That will never work., I want buildings now. You can take leadership on this. Are you the only active mapper in your city or region, or one of only a
