[Imports] [Imports-us] Address Data Import for Fulton County, Georgia

Sun Jan 12 20:30:10 UTC 2014

The source code, converted file (used in the application), and sample
files have been updated. The first two need to be downloaded (again) for
testing the application. The changes I've made is to save the log
displayed in the window to another file, add some control as to what is
output into the log window, correct the name of addr:housename, and also
add in the tags addr:postcode and addr:city. The log file is saved to
the same location as the OsmChange file, but with a .log extension.

Note that some of the cities around here (for example, DeKalb County)
are mixed case. Currently, the city case is just converted to title case
(first letter capitalized, the rest lowercase). This will need to be
corrected before the import begins.

Source code: https://github.com/saiarcot895/osm-fulton-address (use the
geos-library branch)
Converted file:
https://drive.google.com/file/d/0B30vrP6AZTFybUR2dE50b2x5ajQ/edit?usp=sharing
Sample file:
https://drive.google.com/file/d/0B30vrP6AZTFyYldqT0hJaVVCdGc/edit?usp=sharing
Sample log:
https://drive.google.com/file/d/0B30vrP6AZTFyOGJEeTkwanFscVU/edit?usp=sharing

Saikrishna Arcot

On 01/12/2014 01:27 PM, Saikrishna Arcot wrote:
> Hi Jason,
>
> I thought I used all lowercase. I'll check and correct the naming of
> addr:housenumber.
>
> The source data also includes zip codes. This would go in addr:postcode,
> correct? I can easily add this as a tag to be imported.
>
> Part of the reason for this check is that it wouldn't make a sense for
> an address to be on the street; instead, it should be off to the side,
> near the entrance of the building/business.
>
> If the address doesn't match a street name in the given BBox, it is skipped.
>
> Saikrishna Arcot
>
> On 01/12/2014 01:13 PM, Jason Remillard wrote:
>> Hi Saikrishna,
>>
>> Just a quick look.
>>
>> - The street number tag is addr:housenumber, not addr:houseNumber. OSM
>> tags don't use CamelCase
>> - didn't the source data also have zip codes?
>> - If you are going to dump an address, you should write it out into a
>> separate file that will be reviewed by hand. These are the interesting
>> bits..
>> - I am not sure the check that looks for addresses too close to a
>> street makes sense.
>> - I don't see a check in the code to look for addresses that don't
>> match any street name.
>>
>> Thanks
>> Jason.
>>
>> .
>>
>> On Sat, Jan 11, 2014 at 6:58 PM, Saikrishna Arcot <saiarcot895 at gmail.com> wrote:
>>> Another update:
>>>
>>> I've added checks into the application to make sure that addresses are
>>> between 5 and 100 meters from the street centerline, and that each address
>>> is at least 4 meters from another address. The source code located here has
>>> been updated. Note that the code with the distance checks is in the
>>> geos-library branch, not the master branch. I've updated the file here to
>>> show a sample output.
>>>
>>> Saikrishna Arcot
>>>
>>> On 01/09/2014 11:54 AM, Saikrishna Arcot wrote:
>>>
>>> (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 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. 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 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 <clifford at snowandsnow.us>
>>> 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
>>> Imports at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/imports
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Imports mailing list
>>> Imports at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/imports
>>>