This is a file I have prepared which shows the data after it was translated to OSM schema:
This was then converted to 30 sections for manageability and to ease collaboration. See the table on the import page.
I have checked that this data is compatible with the ODbL.
No specific license was provided, so I inquired with the data owner. They assured me there are no restrictions on the use of the data.
This data source comes from the Waukesha County Land Information Systems and contains approximately 163,000 address points. The dataset contains: housenumbers, streets, zip codes, and post office cities. In addition, the state field was filled in.
PostOffice: converted to addr:city=* (as described on addr:city=* the postal service city is the name of the USPS post office that serves the address’ ZIP code)
UnitNumber and UnitType: some cases were deemed useful to tag separate units, such as semidetached housing with a shared housenumber, or for determining ranges of units in buildings in a complex with one shared housenumber. Individual unit numbers where tagged as addr:unit=* and ranges were tagged as addr:flats=*.
This proposal looks good to me overall. Thanks for keeping a copy of the permission somewhere persistent.
Address_Use (it was considered that building=* could be set from this, but this refers to address use, not building construction purpose)
As long as you’re conflating with buildings, you could map these values to building:use. Otherwise, perhaps you could spin off a MapRoulette challenge to find the right place to put values like “Pub/Rec/School” from the dataset.
Has the county published a schema or specification for this dataset? Such specifications usually come with a full table of the abbreviations in use. That would be preferable to hunting for abbreviations in the dataset.
By the way, I love that the county has published the original proposal and final report describing the county’s addressing system. That could be very useful for OpenHistoricalMap.
addr:street=“Yorkshire Traces” should probably be “Yorkshire Trace” based on the name of the associated street in OSM. This seems to be a general issue with Trace vs Traces.
addr:street=“Arbor Drive Extension?” Not sure what this should not be, but there probably should be a “?” in the street name. This seems to be a general problem as there are 15 addresses where addr:street contains “?”
In general there seems to be quite a few cases where addr:street doesn’t match the current OSM streets, and where OSM seems to be wrong (according to the USPS). I presume you will detect these during the import and research what the correct tagging should be.
The following addr:street values probably need to have the letter after “Mc” capitalized:
The following addr:street values probably need to have the letter after “Mac” capitalized:
This addr:street doesn’t look right:
Lovers Ln;N124W16826 Lovers Lane
The above situation happens 22 times in the data. Oddly, the housenumber that has been inserted in the addr:street tag doesn’t always match the value of the addr:housenumber tag, and in some cases addr:street appears to contain two different street names, e.g.
The original “street number” in the dataset looks like N117W17890, which I assume to be that address locator system the county uses. I think this last example would translate to 17890 Augusta Court and 11766 Medinah Court. I’ve never been sure what to do about a building that legitimately has two different addresses on two different streets. The least risky approach I’ve found has been to map two different address nodes within the building, but this doesn’t recognize that the two addresses are equivalent.
Thanks @tekim for finding these the formatting errors. I’ll update the appropriate files in the coming days.
Indeed, part of the QA process is running JOSM/Plugins/FixAddresses which compares addr:street=* with the name=* of the nearby street. For this reason, I’m not too worried about finding all the incorrectly formatted street names, as any addresses which differ from the current street name in OSM will be flagged (I used the same process in my Milwaukee import, and it allowed us to find some names unfixed from the TIGER roads import, which is nice). Nonetheless it’s good for us to catch what we can now.
I’m not sure about all of those, at least Mackenzie and Macintosh seem right without the letter after “Mac” capitalized. I’ll have to look at these individually.
It’s a good idea (although it may be odd to see lots of building=yes + building:use=residential). I’ll take note of the potential for using this in the future, as at the moment I’d rather focus my attention to addresses.
I couldn’t find one. Would this help in any way that couldn’t be done by comparing with the surrounding road names? I could ask the data owner if it has enough of a benefit to us.
Of course all require investigation as to local use.
I have looked further into this and indeed in the original source data there are two address points at the same location (or as near as I can tell). I suggest they both be left in the data, and upon import, perhaps separated by a couple of meters for cartographic purposes. It would be interesting to talk to local authorities (or do some field work) to determine why this is done. Perhaps these are duplexes and there really are two separate residences in the same building?
I think this is unlikely. If we look at a more typical address point and compare the StreetNumber to the Full_Address, the StreetNumber is always the grid identifier for the street, followed by the house number.
As I mentioned in another reply, there are two address points in the source data at the same location (as near as can be determined visually) here. I think we agree that, baring some insight from local authorities to the contrary, both should be represented in the final data to be imported - although that is an imperfect solution. Here is the source data for one of them (I have outlined the relevant parts in red):
My contention is that this should be tagged in OSM as:
(plus other relevant tags)
Here is the source data for the second one:
My contention is that this should be tagged in OSM as:
(plus other relevant tags)
This approach is similar to how the address to the northwest was handled by the importers. Here is the original source data for this address:
Here is how this address was tagged in the proposed import data:
In fact there are 74,657 addr:housenumber tags that have a similar format (JOSM query “addr:housenumber”~“^[NSEW][0-9]+[NSEW][0-9]+.*$”) in the proposed import data out of a total of 163,290 addresses.
So my suggestion as to how the first two addresses should be tagged is consistent with the way the rest of the data in the proposed import is being handled.
Sorry, I was mistaken in thinking the import was generally mapping the Site_Number field to the addr:housenumber key rather than including the whole StreetNumber. This makes a lot more sense now. The USPS ZIP code lookup tool recognizes “W179N11766 MEDINAH CT” (though I can’t tell from aerial and street-level imagery whether these residences even get mail delivery). In terms of formatting, is it more correct to smoosh the two coordinates together, as the USPS does, or separate them by a space or dash, as seen in this article?
Both Medinah Court and Augusta Court are in a condominium development, which could explain the overlapping address points. (Ignore the links in this press release; the original development’s website has been repurposed for a similarly named development elsewhere.) In my neck of the woods in California, these are called “air parcels” and some GIS departments keep them in a layer separate from address points per se. I guess the ideal for OSM would be to scoot each address point toward the corresponding entrance, disregarding actual property rights, but obviously that isn’t something a bulk import could be expected to do in a first pass.
I don’t have a strong opinion (other than to be consistent within Wisconsin), but given the source data, the USPS data, and the way the proposer of this import has formatted the data, it seems like “smoosh” is the way to proceed.
It also recognizes “N117W17890 AUGUSTA CT”, so best to include them both, and as you suggest, when possible, move them apart and toward what we assume to be their applicable entrance.