(In case my previous message doesn't go through) For the record, I took a quick look at the converted data (after processing and all) in JOSM, and the address data seems fairly accurate (at least in midtown Atlanta). There are a few points that are half-a-house over and some building that have two points, but mostly all points seem to be located correctly.
A slightly bigger issue I'm seeing is POIs and buildings that have an addr:housenumber, but no addr:street, which makes it difficult to determine what street the building is on and to detect that as an existing address. In the Atlanta region, there are a few <http://overpass-turbo.eu/s/1Zd> that can probably be manually handled. Currently, I'm ignoring anything that has an addr:housenumber but no addr:street, but this will cause some duplicate data. As a status update, I can generate a sample OsmChange file after running it through my application, but it does very few checks to see if the address is located at a reasonable location. I've uploaded a sample file for review so far here <https://drive.google.com/file/d/0B30vrP6AZTFyYldqT0hJaVVCdGc/edit>. _Note that addr:city is missing._ _/ /_ I'll get in touch with the Fulton County GIS to see if they can allow the building footprint data to be used in OSM. However, I don't see how the tax parcel data can help in OSM. Saikrishna Arcot On 01/09/2014 11:49 AM, Saikrishna Arcot wrote: > For the record, I took a quick look at the converted data (after > processing and all) in JOSM, and the address data seems fairly > accurate (at least in midtown Atlanta). There are a few points that > are half-a-house over and some building that have two points, but > mostly all points seem to be located correctly. > > A slightly bigger issue I'm seeing is POIs and buildings that have an > addr:housenumber, but no addr:street, which makes it difficult to > determine what street the building is on and to detect that as an > existing address. In the Atlanta region, there are a few > <http://overpass-turbo.eu/s/1Zd> that can probably be manually > handled. Currently, I'm ignoring anything that has an addr:housenumber > but no addr:street, but this will cause some duplicate data. > > As a status update, I can generate a sample OsmChange file after > running it through my application, but it does very few checks to see > if the address is located at a reasonable location. I've attached a > sample file for review so far. _Note that addr:city is missing._ _/ > /_ > I'll get in touch with the Fulton County GIS to see if they can allow > the building footprint data to be used in OSM. However, I don't see > how the tax parcel data can help in OSM. > /Saikrishna Arcot/ > On 01/09/2014 11:08 AM, Serge Wroclawski wrote: >> >> On Thu, Jan 9, 2014 at 10:59 AM, Clifford Snow >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> I agree with Martijn. Addresses add real value to OSM. With an >> address node, routing works better, adding POI information is >> easier, and it aids disaster recovery work. I'll admit, building >> outlines look nice and alone they aid mappers adding POIs and >> also can be used in disaster recovery work. So each adds value. >> >> >> >> About the disaster recovery work. I had a conversation with a >> CERT member last week. He was frustrated using address >> interpolation to plan for response efforts. He would love to see >> address nodes added. >> >> >> Let's not confuse addresses as raw nodes with no addresses. >> >> That's a bit like me saying a healthy meal is better than junk food, >> and the response being that junk food is better than no food. It's >> not what I'm saying. >> >> The issues with address points are: >> >> 1. They're often in the wrong places. You just don't know it until >> you have building footprints to compare it to. >> >> 2. There's not a whole lot of data about addresses being updated >> >> 3. (as was brought up in the NYC building point discussion) There's >> no code that I'm aware of that correctly parses address points inside >> building polyogons in such a way that non-addressed POIs get the >> address attributes. >> >> 4. If geolocation is the issue (which it seems to be), then we could >> feed that data to the geolocator directly, rather than placing it in OSM. >> >> - Serge >> >> >> _______________________________________________ >> Imports mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
