Re: [Talk-us] USFS Roads - name and ref
Abbreviations are predominant in US highway refs, so I think that it is fine to use one in USFS road refs. At some point in time I had used ref=USFS xxx but changed stuff that I had edited to ref=FS xxx. The usage of FS in Michigan is largely a product of either my editing directly or my discussion with other mappers (and looking at Overpass Turbo and Taginfo, something like 45% of all refs with the string "FS" in them...). I don't remember really, but I think I started with USFS because it was nearly entirely unambiguous, and then I switched because the usage of FS was more common. ref:usfs=FS looks wrong to me, if usfs is in the key, then it doesn't belong repeated in the value (unless there's 2 reference systems in use, which there are, https://en.wikipedia.org/wiki/Forest_Highway is not the same thing as the Forest Service logging roads)). The use of ref:usfs also has the problem that it hides useful data on general purpose maps that don't specifically use it. If ref is to be used, I expect you won't arrive at any real consensus about what to use as a prefix, because it's easy to have an opinion about it (bikeshedding basically). I guess if enough people pick one we might get close. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Townships, Counties, Great Lakes
I've recently been working on adding administrative boundaries for townships in Michigan (old USGS paper maps show the boundaries, I'm tracing those). Previously I've concluded that counties in Michigan don't really extend into the Great Lakes. The sheriff has jurisdiction on the water (extending into the water near adjacent counties), but that's about the end of it. For the most part Michigan counties are modeled like that, using the shoreline as part of the boundary. What I am wondering about is whether townships should also use the shoreline, splitting it into quite a few more pieces than currently exist. The alternative would be a ways that share nodes with the shoreline. I'm leaning in that direction but I figure it will be a pretty noisy change, so I'm asking what people think before proceeding. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Great Lakes Circle (Tours, bicycle) GIS-folk?
In the UP, USBR 10 isn't much more than the shoulder of US 2. It's mostly paved, and every year there are fewer extremely narrow sections! I guess there are probably a few signs, but not many. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Great Lakes Circle (Tours, bicycle) GIS-folk?
I live in Michigan and regularly drive US 2 in the Upper Peninsula. The Lake Michigan route isn't signed in any sort of meaningful way. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them
There's lots of discussion of these points as a mapping resource. The thing is, they don't need to exist as current OSM objects for mappers to use them as a resource, there's lots of other ways to use them as a reference. The deleted points can be extracted from the mechanical edit changesets or processed out of a current GNIS dump or whatever. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Michigan Forest Land
The US forum is pretty low traffic (a couple posts this year), so I guess a topic wouldn't bother anyone: https://forum.openstreetmap.org/viewforum.php?id=20 There's also a michigan channel on the osm us slack. ( https://slack.openstreetmap.us/ ) On Wed, Mar 13, 2019 at 10:58 PM Kevin Kenny wrote: > > (Is there a Michigan-specific forum that we could take this to? We're > probably boring the daylights out of most of talk-us.) > > On Wed, Mar 13, 2019 at 9:16 PM Max Erickson wrote: > > > The management units in the data are subunits of the state forests > > still. For instance, "Gwinn Forest Management Unit" is/was part of the > > Escanaba River State Forest. > > > > The question is which data is better to present to the average end > > user. I guess if the state isn't using the state forest names anymore > > it makes sense to have the management units in OSM. But then because > > people know the older names, does it make sense to also have the state > > forests? > > What I see in the data doesn't match your description. 'Unit_name' > appears to be one of sixteen large rectangular regions, and then > 'management_name' is a fairly small region. > > I've sliced the data both ways, and put the results in > https://kbk.is-a-geek.net/tmp/mi_sf.zip, so that you can open the data > in JOSM and see what's up with it. DO NOT IMPORT - the translation is > very rough and doesn't even pass JOSM's validation - I'm simply > sharing it so that locals can see whether either division makes any > sense in the local context. > > Simply coalescing the data led to topological problems, as I > anticipated. I did some jiggery-pokery with ST_Buffer in PostGIS to > force the topology to be consistent. The result is that every parcel's > boundary is set back 2.5 metres from where it was in the original data > set. This is surely no big deal as far as the map is concerned, but > cuts way back on the validation errors. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Michigan Forest Land
On Wed, Mar 13, 2019 at 11:20 AM Kevin Kenny wrote: >> >> Complicating things, the state seems to have moved away from saying >> much about the top level state forests. But I think they are probably >> still the right thing for a general purpose map. > > > Right. That's why I was talking about coalescing compartments that have the > same management type and name. The table in my earlier message shows the > number of compartments to be combined for each facility. The management units in the data are subunits of the state forests still. For instance, "Gwinn Forest Management Unit" is/was part of the Escanaba River State Forest. The question is which data is better to present to the average end user. I guess if the state isn't using the state forest names anymore it makes sense to have the management units in OSM. But then because people know the older names, does it make sense to also have the state forests? Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Michigan Forest Land
The compartments likely aren't the right data for a general purpose map; I'm not entirely sure, but they seem to be the basic management unit for state forest land, so when they consider a cut or whatever they consider it for that area. For OSM, the right things is probably to have individual objects for each state forest, game area, park, etc. Complicating things, the state seems to have moved away from saying much about the top level state forests. But I think they are probably still the right thing for a general purpose map. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Forest Routes
As other have mentioned, there are many numbered roads managed by the USFS. They range in development from closed, abandoned log roads to well maintained pavement. I map them using the FS prefix. For the general public one of the main uses is the publication of motor vehicle access conditions: https://www.fs.fed.us/recreation/programs/ohv/ohv_maps.shtml Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER place confusion
Just comparing relations with place= tags to the corresponding nodes works: http://overpass-turbo.eu/s/CjI Obviously not an OSM place=city there. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] TIGER place confusion
Many of the administrative boundaries imported from TIGER have a place= tag that reflects the legal type of incorporation of the municipality rather than a sensible value for the OSM place tag (which would give some hint about the relative prominence of the place). This confusion has gone under the radar, as openstreetmap-carto doesn't render place labels from ways and relations: https://github.com/gravitystorm/openstreetmap-carto/pull/2816 Deleting the imported place= values (or perhaps moving them to some other tag, say something like incorporation=) would directly make the data more accurate and improve maps that render place areas without accounting for the confusion in the data. What do people think about deleting (or adjusting) the place tag from imported US administrative boundaries? Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Gravel roads and surface tags in the US
>I grew up in an area with these kinds of roads and I don't think >they're technically compacted. The gravel, which is crushed >limerstone, is laid down and due to its chemical properties creates a >smooth surface after several months of traffic. Having read about this some since Tobey mentioned it on Slack, the compaction is often meant to come from traffic. In the Midwest the material is often from local "gravel pits" which are glacial material, so a mix of sand and rounded stone. I think they do some sorting and remixing of the material before using it for road surface construction, and they definitely add clay as a binder. I think the use of clean stone (the wiki gravel) is more common for ornamental driveways than for any road meant to bear much traffic. Apparently part of the issue is that there aren't many built roads in the UK (and Europe in general) that aren't sealed. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] mechanical edit of 'address' tags in New York
Another proposed mechanical edit, splitting 'address' tags in New York. The tags are mostly from an import of libraries. Uses the same code as the MA splitting: https://github.com/maxerickson/massadd There's a lot less of them, only 290: https://gist.github.com/maxerickson/3e5d6cb9f5b5306b8d15901b8fb351b1 Only objects where the "address" tag is correctly split and there are no conflicts with existing tags would be altered by the edit. If the address tag has a po box in it, it is stored in the contact:pobox tag, which I guess can be controversial. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] 'address' tags in Massachusetts
>There is a talk-us-massachusetts@ and I think review of your proposed >mechanical edit should include that list. Okay. This is pretty preliminary still, I just decided that feedback was a good idea. Does that list overlap enough with this one that you forwarding the message would be sufficient? >I suspect people would be amenable, but it would be good to publish the >code, and the proposed files to upload, so that they can be reviewed. I've put the code at https://github.com/maxerickson/massadd I guess I should have mentioned in the earlier message that it does some (conservative) formatting cleanup. Tidying uppercase and expanding a small number of abbreviations. There's no OSM file because I don't think it is ready for upload (it's quick enough to generate if you have curl and python3 installed). The data at the gist does fully reflect the changes the script would currently make. >Also, it certainly makes sense that there are some values that are hard >to parse. The obvious approach is to just leave them out (and leave >them for manual fixing or another day), but I'm not really sure exactly >what you are proposing to do. At the moment if the 'address' field is not parsed without error the script doesn't do anything with that object. There's some 'address' fields that are parsed incorrectly (mostly they include a po box or a unit and could be excluded by matching for those). That's part of the not being ready. >As for nodes with both the old addr tag and new ones, you imply that the >simplest way is to clean them up before a mechanical edit. But that >implies that if they aren't fixed first, you might do something to those >nodes, and that seems against the spirit of the mechanical edit policy, >which involves refraining from changes that you can't basically prove >are correct. But I don't expect you'd be doing that, so perhaps you can >expand on what you meant. Yeah, it isn't implemented yet but that is what I would do, skip those objects. Overall I'm not in any hurry, but the majority of the address parse correctly and after an edit would be used by more data consumers and show up more clearly in editors and so on. It's something like 100 manual fixes to clear the way for about 3900 automatic splits. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] 'address' tags in Massachusetts
Many POIs in Massachusetts have reasonable address information stored as a single value in the address tag (mostly from imports before the 'addr:*' scheme was established). Something like 1/2 of the uses of 'address' in OSM are in MA. I'd like to do a mechanical edit that parses the individual pieces of the addresses and moves them into the appropriate tags. Here is the work in progress data for the parsing: https://gist.github.com/maxerickson/1ece717992043316bc615b8a98821efd There's a few dozen addresses where the simple parsing I've written doesn't work (lines start with "ERROR") and a few dozen more where a PO Box means that the proposed parsing is wrong, with the PO box appearing in the street or such. There's also about 100 occurrences of an existing 'addr:*' value that does not match the data in the 'address' tag (these aren't visible in the gist). The simplest way to deal with these issues is to clean them up before applying a mechanical edit, so feel free to take a look at a couple and clean them up. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways
In National Forests, USFS road data usually has sensible information about the suitability of roads for general traffic. There's an imagery layer showing the Forest Service data: https://www.openstreetmap.org/user/Richard/diary/26099 I prefer opening transformed data as a layer in JOSM. Here's the script I use to translate the data: https://gist.github.com/maxerickson/32ca41e72458b12a5734f97f75800448 Followed by a command like ogr2ogr /share/gis/extracts/test.shp /share/gis/USFSOsm/ -clipsrc -85.2 46.2 -84.5 46.6 to clip out an area of interest. The advantage is not having to remember a second set of visualizations for the various road features. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Vermont Town Boundaries import
I'm working on figuring out the licensing for a similar import in Michigan (https://github.com/maxerickson/michigantownships ). I've put together a translation for ogr2osm (https://github.com/pnorman/ogr2osm) that takes a shapefile with boundary polygons and outputs an osm file with merged relations, where 1 shared way represents the boundary between adjacent relations. It seems there is a town polygon file (http://geodata.vermont.gov/datasets/0e4a5d2d58ac40bf87cd8aa950138ae8_39), it might save some work to adapt the translation file I have there. I haven't looked at the osm data, if many town relations have already been created it won't help merging the new geometries with those relations. The relation simplification should work as is, you'd just need to adjust the filterTags tags function for the VT data. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiger name issue in New York
I took note of it just seeing the name in parking lots in towns and on obvious driveways. It seems armchair cleanup would be able to address those. Maybe I will get over my reticence to edit the wiki and make a page for listing these sorts of "structural" issues with Tiger data. Could also list things like counties with *extremely* poor geometry or high numbers of service roads imported as residential. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] tiger name issue in New York
About 1600 highways named "Adirondack Park" and another 300 named "Adirondack Park Preserve". Mostly service drives that are in Adirondack Park, but it seems unlikely that they are all actually named that way. http://overpass-turbo.eu/s/vDk Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Coolidge Corner, Brookline, MA has wrong zip code
So just to follow up, what happens is that nominatim treats items tagged with "addr:postcode" but not "addr:housenumber", "addr:housename" or some type of POI tag as sources of postcode data. There are quite few objects that will match that pattern that probably aren't intended to define post codes. This Overpass API query does an okay job of flagging them: http://overpass-turbo.eu/s/t5g It causes the server to run out of memory for large areas so just zoom in and try again if that error happens. There's probably some more tags to exclude but it already filters down to a manageable number of objects. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Coolidge Corner, Brookline, MA has wrong zip code
Nominatim calculates 02118: http://nominatim.openstreetmap.org/details.php?place_id=498867 Most of the data seems to have the correct addr:postcode: http://overpass-turbo.eu/s/t5e (The query includes postal_code but there aren't any in the data) So what is Nominatim looking at to come up with the calculated value? I think the next thing to check would be boundaries enclosing Brookline, not sure if that is how nominatim works though. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Integrating our open source data into OSM
Hi- It would be useful if you would describe how the data has been collected and what other databases it may include information from. OSM takes a fairly cautious approach to data rights, so it is a necessary step to any import to clarify where the data has come from. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr
> I think that we need to ask MapBox to revise the 2017 Tiger layer. Ian Dees put together the 2017 layer. There is also some kind of rendering problem with name labels on short, curvy ways, the characters are bunched up and overlapping and then there are gaps. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Something very bad happening in Maryland?
More at: https://lists.openstreetmap.org/pipermail/imports/2017-October/005181.html At the moment they are blocked: https://www.openstreetmap.org/user_blocks/1587 It can be hard to say if the node only changesets are broken. JOSM will split changes up like that when they exceed the API limit (10,000 objects) and the ways will appear in a later changeset. Of course they are bad style whether they are broken or not, the import should be split into smaller more manageable pieces. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Tracking Redaction Review
I setup a sheet to try to consolidate information about what has been looked at: https://docs.google.com/spreadsheets/d/1MbF4BptFvkY_Cp0zh1OKBxt_E9tdXklxRDfMW0baBvU/edit?usp=sharing Open to anyway so just fill in a state once it is reviewed. I went through the earlier thread and added anything mentioned as done. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Redacting 75, 000 street names contributed by user chdr
I reviewed about 40 ways in New York. Here's an Overpass script for finding the ways that have not been changed since the redaction: https://gist.github.com/maxerickson/e02651cce99af983949b91f8d471fb23 The ways are clustered quite a lot. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr
Yeah, I'm about done with Michigan (40 ways to check). I just used the OpenData plugin for JOSM to open a filtered csv, which made it clear there were a few clusters. I downloaded the data for each cluster and used a search "type:way user:woodpeck_repair" to add the ways to the todolist plugin. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] dubious church node
>One more thing to know about GNIS: entries are never deleted. One minor exception to this is if they determine that a given feature has 2 IDs, one of the IDs will often be removed. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] dubious church node
There's a fair chance that a GNIS location is off by a couple miles. A little bit more information from GNIS is available by putting the ID into https://geonames.usgs.gov/pls/gnispublic/ It lists "Mill Creek Baptist Church" as a variant name. From time to time I come across a GNIS entry that is off by dozens of miles. I figure these must be typos during the location entry or something like that, as many of them are located well. In this case I would assume they only knew the church was in Nashville near Mill Creek. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] dubious church node
Yeah, a Google search for "Mill Creek Church nashville" has http://freepages.history.rootsweb.ancestry.com/~nashvillearchives/millcreek.html as an early result. It says the church building has been dismantled but mentions a cemetery, which still exists nearby the mislocated osm node: http://www.openstreetmap.org/way/53498031#map=16/36.1182/-86.7267 Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Functional Classification question in the Kansas City area
Given that the HFCS can simply be added as another tag, I don't see any reason to force OSM tagging away from what is sensible just to line up with what the state says. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] "System Continuity" in the Functional Classification network
Broadly speaking, yes, such continuity should apply. Maybe not using exactly the same rule as the US DOT. In practice there is an overfocus on observing how a given stretch of road is built and an underfocus on the role it plays in the network. My pet example is this stretch of US 2 & 41: http://www.openstreetmap.org/#map=16/45.9090/-86.9901 Several times it has been upgraded to trunk, to reflect that it is dual carriageway. But it doesn't make any sense for a trunk road to run the short distance between a tiny village and a small town. Lately I've been leaning towards classifying most of US 2 as trunk, as it is the major east-west corridor in the region. But the difference between primary and trunk should be for the longer stretch of road, not just to distinguish that one stretch is overbuilt. Another example I see in the data is short cul-de-sacs tagged as tertiary, sometimes alone and sometimes as the continuation across an intersection of a longer road. The sensible classification for these is frequently unclassified, because they serve as the public access road for a small commercial or industrial area. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] anyone know what software is generating these Q/A Notes?
It's StreetComplete. Newer versions include the app name in the note: https://github.com/westnordost/StreetComplete/issues/308 Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Territorial municipalities, Guam's villages
>> Max Erickson writes: >> >> The image the linked image was traced from provides no provenance >> (beyond "Own work"). It's tough to go from there to being sure that >> derived data is okay to contribute to OSM. > >It is explicitly CC BY-SA 4.0. Does OSM have a problem with that? > >SteveA >California I don't claim to speak for the gestalt that might be OSM, but all we see there is that a Wikipedia editor, "Mr.Election" has asserted CC BY-SA 4.0 over their contribution to the work. They give as a source "This SVG map was traced from Guam-administracja", so to evaluate the copyright status of the SVG, it is also necessary to evaluate the copyright status of the Guam-administracja image. I don't see sufficient provenance to come to a safe conclusion about the status of the Guam-administracja image. In any case, it seems similar boundaries are available from the Census. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Territorial municipalities, Guam's villages
The image the linked image was traced from provides no provenance (beyond "Own work"). It's tough to go from there to being sure that derived data is okay to contribute to OSM. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger Zip Data Removal Project (Update)
Frederik wrote: > I notice that at least two people who have negatively commented on your > recent edits in changeset comments - Max Erickson and Steve A - are > regulars on this mailing list, but they didn't get involved when you > discussed the issue here four weeks ago. As this is my second message, I'm probably not a regular on the list. I saw the thread but didn't really have anything to add to the comments from Jason Remillard, Mike N and Walter Nordmann. I do see the particular edits as more or less noise but won't bother Hans further if he chooses to continue with them. Hans, I apologize for any discouragement my message caused. I tend to write tersely and don't always do a good job of avoiding abrasiveness. Max (sorry if this message breaks threading a bit, I don't get messages delivered and am experimenting with replying from an archive) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Prototype tool to conflate/import Microsoft buildings
There's several scripts for outputting some information, generating modified osm data and extracting buildings that aren't present at all in OSM. There's more description in the readme: https://github.com/maxerickson/osm_ms_buildings Only tested against the Michigan data which has 8140 geometries, concentrated in the Detroit area. Not sure how things will go with larger datasets. A clipped out region of reasonable size should work fine (the scripts complete in a few seconds for ~10,000 buildings on my older laptop). For Michigan/Detroit, the main takeaway is that a *lot* of the buildings are already in OpenStreetMap. This histogram is calculated using the largest single overlap for each existing OpenStreetMap building (data at https://drive.google.com/open?id=0BxwWB33rZeUVU2FVaEVGUk9sNFU ): bin count 0.0-0.1 7645 0.1-0.2 41 0.2-0.3 34 0.3-0.4 53 0.4-0.5 64 0.5-0.6106 0.6-0.7112 0.7-0.8280 0.8-0.9954 0.9-1.0 5133 The areas there are presently calculated stupidly, in WGS 84, but I think the relative information should be fine. So of the ~14422 buildings present in OSM, 7630 don't overlap the Microsoft buildings at all and 5 or 6 thousand overlap quite a lot. Of the visual review I've done, I'd say that the existing OSM buildings tend to be more detailed and line up more closely with current Bing Imagery. Separately, there are 410 buildings in the Microsoft data that do not exist in OSM (take a look https://drive.google.com/open?id=0BxwWB33rZeUVNTVJVmNQcEg2RHM ). A more sophisticated matching algorithm is probably a good idea, but for the Detroit data I would be pretty comfortable mechanically adding the heights for the buildings where the overlap is roughly 80% or higher and then doing a more manual process for the new buildings (checking against newer imagery?), and then also doing some sort of more manual process to capture the information from the several hundred buildings with smaller overlaps. Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
