|
I have a problem locating an address (10000 S 400 E, Markleville, IN, 46056). When I search for 46056 alone it brings up two towns, Emporia and Markleville. People in Emporia have a 46056 zip code, but they have Markleville addresses. I suspect that when I search for 46056 that Emporia should not be listed. If I (incorrectly) change the city in the address above to Emporia the address is correctly plotted on the map. I think there is some kind of incorrect zip code entry that makes nominatim think that people have Emporia addresses when they should all be Markleville addresses. What would be the way to correct the problem? Thanks. |
|
The problem with your address is not the postcode but the administrative boundary for Markleville. It only encloses the village itself. Road S 400 E is outside the village according to that. Nominatim then messes up a little bit as you can see on the details page for the road. It actually places your road into Emporia because it is the closest village that does not have a boundary defined. To correct the situation, I'd recommend to do two things: add a addr:city=Markleville tag to your street, so that Nominatim knows to which village the road belongs, and then define a proper boundary relation for Emporia, so it knows to which village the road does not belong. But DOES this road belong to Markleville adminsitratively? I bet no, otherwise the boundary of Markleville would include the road and its surrounding households. So These households belong to another administrative town/city, Emporia, and Emporia has several ZIPs. To correct this the Germany solution (which is to map the postal code areas independantly of administrative boundaries) is a good solution. It allows a town to have several postal code areas, or the same postal area covering multiple towns or parts of them. And it's much easier than tagging each address node or street in that area.
(30 Nov '12, 11:34)
Verdy_p
And effectively, Emporia needs its own administrative boundary (covering that street, even if its postal addresses are handled in Markleville) : here again the postal area of Emporia does not cover the whole administrative town but only a part of it, excluding this street which is in another postal area. So: add the administrative boundary for Emporia, and add the two distinct boundaries for the postal areas of Emporia and Markleville. You then don't need to tag the streets to their postal areas, this is implicit. But you still need to associate the households to their street relation.
(30 Nov '12, 11:41)
Verdy_p
Note also that the admininstrative boundary of the city of Markleville has two small enclaves that are excluded administratively. To which city they belong then administratively? It's unknown (OSM does not specify it for these enclaves), even if they are in the postal area of Markleville (also not specified: Nominatim "guesses" it should be Markleville). Once again the postal area does not match the admininstrative boundary of the city, and the German solution (mapping separate postal boundary relations) is excellent to cover these cases without complex tagging for each household or street.
(30 Nov '12, 11:54)
Verdy_p
4
As Dennis was looking for the address '10000 S 400 E, Markleville, IN, 46056', I dared to assume that Markleville is part of the postal address for this street even though it may not be within the administrative boundaries of the village. The answer relates to exactly this special case. The area of the postal code is completely irrelevant here, it is the town name that prevents Nominatim from finding the address. (Nominatim does get the postcode completely right, searching for 'S 400 E, 46056' returns the correct street.)
(30 Nov '12, 12:43)
lonvia
|
Why, if you are searching (presumably) for the zipcode alone would it not make sense that the database returns all inhabited places it locates within that zipcode?
Germany has an interesting concept to solve this problem (and to avoid heuristics that may fail) : it maps boundaries for postal_code areas that frequently do not follow the administrative areas and their hierarchy of admin_level's.
This case is not unique, it exists in many countries, and postcode areas generaly do not evolve at the same time as administrative areas.
The same could be said to regional phone areas (the 3 digits in US and Canada before the local 7-digit phone number).
Circeus, there is nothing inherently wrong with returning all cities/towns that share the same zip code. That could certainly be useful as a feature.
My road has tags that point it to the 46056 zip code so it should be able to figure out that I have a Markleville address. They are TIGER tags so maybe there needs to be a "postalCode" tag? When nominatim tries to find me it seems to be insisting that I have an Emporia address. I think that because it returns Emporia first and then Markleville when searching only by ZIP code.
I'm just trying to figure out how to corretly locate my address.
You might go to the Nominatim page (http://nominatim.openstreetmap.org/search) and enter different terms and see what results you get. Note that you can click on Details for each result and get more info about it. So, for example, the zip codes appear to be nodes that aren't in OSM. There are two nodes for 46056, so there's no reason why Nominatim would know you're in one or the other. Your address doesn't have a road name (it's x,y style), which is something that might help it determine the correct city (municipal boundaries are parents for roads within them).