addr:street=“Chevy Chase” should probably be “Chevy Chase Street” based on the name tag of the street in OSM.
addr:street=“Cth Vv” should probably be “County Highway VV” (second V capitalized) based upon name tag of street in OSM.
addr:street=“Bermuda Boulevard Up” should probably be “Bermuda Boulevard Upper” based on the name tag of the associated street in OSM. (General issue with Up vs Upper)
addr:street=“Campbell Traces” should probably be “Campbell Trace Road” based on the name tag of the associated street in OSM.
“Ush” in addr:street should probably be “United States Highway”
addr:street=“Wembly Circle Lw” should probably be “Wembly Circle Lower” based on the name tag of the associated street in OSM. (General issue with Lw vs Lower)
There are four addresses that do not have a addr:street tag (they also do not have an addr:city tag).
There are four additional addresses that do not have an addr:housenumber tag (and no nohousenumber=yes - although I think these really do have a house number in reality, it is just not in the data)
addr:street=“Walnut Hollow” should probably be “Walnut Hollow Court” based on associated street in OSM.
addr:street=“Green Dragonfly Isl” should probably be “Green Dragonfly Island” based on location (it is located on an island).
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.
That is all for now.
1 Like
The following addr:street values probably need to have the letter after “Mc” capitalized:
Mcallister Way
Mccall Street
Mccarthy Drive
Mcclure Drive
Mccormick Drive
Mccoy Parkway
Mcdivitt Lane
Mcdowell Court
Mcdowell Road
Mcfarlane Road
Mcgregor Court
Mckenzie Road
Mckerrow Drive
Mckinley Drive
Mclaughlin Drive
Mclaughlin Road
Mcleavey Court
Mcmahon Road
Mcnally Lane
Mcpride Lane
Mcshane Drive
The following addr:street values probably need to have the letter after “Mac” capitalized:
Macallan Court
Macarthur Drive
Macaulay Drive
Macintosh Way
Mackenzie Court
Mackenzie Drive
Mackenzie Lane
Maclen Drive
Maclynn Court
Maclynn Drive
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.
addr:city=Germantown
addr:housenumber=N117W17890
addr:postcode=53022
addr:state=WI
addr:street=Augusta Ct;W179N11766 Medinah Court
addr:street=“Fond Du Lac Avenue” should probably be “Fond du Lac Avenue” (lowercase ‘d’)
Double check other French names.
The addr:street value “Legend At Merrill Hills Court” should probably be “Legend at Merrill Hills Court” (lowercase ‘a’ in ‘at’)
Anytime addr:street = "Road " followed by two letters, both should probably be capitalized:
Road Dt
Road Ge
Road Gg
A similar thing applies to county highways.
A similar thing applies to “Town Mm Road”
addr:street=“Ymca Camp Road” should probably be “YMCA Camp Road”
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.
That is a reasonable value for this area. I think it is called grid addressing. It is also used in most of Utah.
Perhaps N117W17890 Augusta Court and W179N11766 Medinah Court. The full “grid identifier” is the housenumber.
If the building really does have two address (and they are not two different units within the building), then this is probably the best approach. I would check with local authorities.
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.
I guess a lot of this work has already been done, so it’s moot now. But maybe we missed something, so if they have documentation handy, it couldn’t hurt.
You are very welcome. Thanks for considering feedback. Of course some are more than “formatting errors”
That is great, but sometimes there is no street associated with the address. For example:
addr:city=Pewaukee
addr:housenumber=N30W27391
addr:postcode=53072
addr:state=WI
addr:street=Green Dragonfly Isl
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 have investigated these
In the first case, it seems the StreetNumber does not appear in the Full_Address, but it is available in its own field, so it could have been pulled from there:
In the second case the Full_Address is obviously invalid, yet there is a StreetNumber and a PostOffice that should have made it into “cleaned_addresses.osm”:
The third case is like the first, the Full_Address does not contain the StreetNumber, but all of the necessary information is present elsewhere:
In the forth case there doesn’t seem to be anything odd about the source record and yet in “cleaned_addresses.osm” there is only addr:state and addr:postcode:
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:
addr:housenumber=W179N11766
addr:street=Medinah Court
(plus other relevant tags)
Here is the source data for the second one:
My contention is that this should be tagged in OSM as:
addr:housenumber=N117W17890
addr:street=Augusta Court
(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”~“[1][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.
NSEW ↩︎
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.
In this case would it be not addr:street=Green Dragonfly Island but rather addr:place=Green Dragonfly Island?
Usually I’ve seen it written here it’s usually just smooshed together.
-
I am not sure of the consequences to the data consumer of that approach. Will most consumers of address data in the US expect only addr:housenumer, addr:street, addr:city, addr:postcode, and addr_state? Maybe it is ok, or even preferred, idk.
-
In “cleanned_addresses.osm” you had this as:
addr:city=Pewaukee
addr:housenumber=N30W27391
addr:postcode=53072
addr:state=WI
addr:street=Green Dragonfly Isl
(addr:street not addr:place)
-
Either way, while the QC tools might flag this, it will be easy for someone doing the import to dismiss the flag, as there is no street, but that false positive masks the real issue of “Isl” not being expanded to “Island”.
-
If you do want to use addr:place, you should search for addr:street tags that end in “Isl”, “Island”, and “Plaza” (and perhaps others).
-
Incidently, the USPS doesn’t seem to recognize the address in question, perhaps it is just for E911 purposes (which is fine, just pointing that out).
Anyway, from my point of view, with just a few important changes this import should be ready to go.
Unlikely. I think we should think of keys like addr:street and addr:city as mapping to different slots in a prototypical address, rather than thinking too hard about the semantics of the values. Some addressing systems have a slot that normally isn’t a street name, or that comes before or after a street name. addr:place might be more applicable and useful to addresses in Puerto Rico, which differ from mainland addresses, but I don’t have a good sense of how it’s being used there.
That is a good way to put it @Minh_Nguyen. A data consumer will probably expect addr:street rather than addr:place for an address in CONUS regardless of whether addr:street corresponds to an actual street.