On Sun, Jun 9, 2013 at 11:07 PM, Clifford Snow <[email protected]> wrote:
> On Sun, Jun 9, 2013 at 3:49 PM, Brian H Wilson <[email protected]> wrote: >>> >>> >> For now I immediately eliminate CONCRETE, DECK, POOL, RUINS and "BUILDING >> INTERIOR" (which is the donut hole in buildings with atriums, since the >> BUILDING polygon has a hole it's redundant) > > > For buildings with openings I'd make sure that you import it as a > multipolygon. For one it helps mappers distinguish the building, it is also > more accurate and third, it looks good! I agree with using multipolygons here, but they're tricky to make and tricky to upload, so when you make your data public for review, this is something we'll want to pay attention to. In addition, we'll want to make sure any upload script you use handles this cleanly. >> Should I tag MISCELLANEOUS STRUCTURE and UNDER CONSTRUCTIONS as >> "building=yes" and be done with it? MISC does not tell me anything and UNDER >> CONSTRUCTION says it will be a building... could be a greenhouse but I doubt >> it. I think those are probably all permitted building projects. > > > I would verify that the buildings under construction are either showing up > on Bing image or on site survey. You may want to exclude them from the > import for manual import later. +1, especially on the on-site-survey. Bing imagery can vary widly by area. In some places, it can be very recent, while in others, it can be widly out of date. >> I started this page some time ago. It is for Corvallis but comes up if you >> do a search for Benton County too -- >> http://wiki.openstreetmap.org/wiki/Corvallis,_Oregon >> >> Most of the county data are online here: >> http://gis.co.benton.or.us/GISDataDownload Thanks. I'll be looking at this after the conference, and I'm sure others will do the same. >> I have taxlots and I have already added address data from taxlots to the >> buildings in PostGIS for exampe >> >> situs building >> -----------------------------------------------------+------------ >> 428 NW 26TH ST CORVALLIS, OR 97330-5423 | yes >> 4500 SW CAMPUS WAY CORVALLIS, OR 97333 | >> 900 SE CENTERPOINTE DR CORVALLIS, OR 97333 | no >> 3516 SE SHORELINE DR CORVALLIS, OR 97333 | no >> 3519 SE SHORELINE DR CORVALLIS, OR 97333 | greenhouse >> 2860 NW POLK AVE CORVALLIS, OR 97330 | no >> >> I intend to conflate the addresses as the streets are already done. And you'll need to do have a name expansion process there as well, since those names are all abbreviated. I suppose you can pretty easily extract the fields here, but you're going to need a name expansion, as well as de-capitalization process for the street name. If you need help with that, we can lend a hand. >> TO me it seems a little bit odd to tag a 100 sq ft shed with an address >> pulled from the taxlot data. >> >> I tend to think the address should go on a point feature placed on the >> centroid of the taxlot and then manually adjusted as needed. You're right that the address doesn't belong on the shed. The best thing IMHO to do is something like this: If there's a single building polygon on an addressed area (the tax lot) then tag that building with the address. If there are multiple buildings, then, as you say, it's a bit trickier. For residential areas where sheds, greenhouses or garages might be, I think the best thing to do, as a rule of thumb, is to tag the largest structure, since that's most likely to be the residence. Otherwise, you end up with these naked address points, which are of value, but less value than a tagged building. If there are multiple addresses which intersect a building, then as Clifford suggests, the best thing to do is keep them separate. That's also what we did in Washington, DC. > In those cases we left it for the importer to manually > determine what to do with the node. I want to emphasize this last statement of Clifford's and come back to it later. >> I just checked their page >> http://wiki.openstreetmap.org/wiki/Seattle_Import >> >> I can handle most of this with python and sql scripts, it's what I do for >> fun as I am forced to do C# programming right now in my day job. :-) Then we >> can get some volunteers to look at the results. > Try to enlist as many people as possible. It makes for a great community > building project. There is some definite gratification from seeing the city > fill up with buildings. Even if you import the low hanging fruit, getting > the community to import buildings is a great opportunity to teach people > JOSM. We are hoping that the imports people did will result in more > ownership of a neighborhood. Same here. This bears emphasis (+1, as the kids say). > I don't fully agree with Serge and Jason on the source tag. Like others I > think it could be useful. A change set tag is appropriate. Until we have > agreement on new import guidelines, I think that is up to you and your > community to decide what is best for you. This is a minor area of disagreement, but a lot of people have been for using source tags on changesets. If nothing else, it preserves metadata better. But what really matters here is this idea of the hybrid, or community import, which sits in contrast to the automated import. What Clifford and Jeff have done in Seattle is to create a community process around the import in a way that didn't exist before[1]. Simply having the know-how, in terms of programming and GIS skills, to complete the process yourself doesn't mean that you should do the process yourself. Instead, Clifford and Jeff have done is to unify the local community around the import, by first doing the kind of analysis, scrubbing and programming that you're doing, but then, secondarily, making a step where community volunteers who were either already OSMers, or were interested in OSM, took ownership. That sense of community and ownership are vital to the long term success of the project, beyond the scope of the import. I'm convinced that these local community imports are really the best way forward at this stage. If they're not viable for a community (such as Paul Norman's town), then there is still value in automated imports, and we can provide assistance there, but wherever it's possible, the community import process should be the preferred method. - Serge [1] In DC, we had several people involved with the import, but the last, crucial stage, was done by machine, and that was our biggest mistake. _______________________________________________ Imports-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports-us
