Re: [Talk-us] Nominatim address lookup
On Sat, Dec 06, 2014 at 01:11:28AM -0600, Paul Johnson wrote: Is it just me or did Nominatim stop checking an external database for address lookups where in-DB addresses aren't available in the US? It never checked any external databases, it just uses house numbers from Tiger where they are missing in OSM. That means that the address down to street level still needs to be in OSM or the search fails. Nothing about that has changed in the last two years or so (although there was a Tiger data outage last weekend but we have been back to normal since Monday) Any partucular address you cannot find anymore? Sarah ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin level for US states
On Tue, Nov 25, 2014 at 10:29:25AM +0100, Martin Koppenhoefer wrote: 2014-11-24 21:18 GMT+01:00 Minh Nguyen m...@nguyen.cincinnati.oh.us: Assuming this table reflects the actual state of the map, most countries have chosen 4 for their state equivalents. Actually, many countries do not have something like a state equivalent, it is a particularity of the USA because they are a federal republic. admin_levels have been invented in order that different borders can be rendered consistently among countries according to the wiki[1]. That's also what I remember. State eqivalent doesn't mean that they must be organised exactly in the same way but that they are roughly at the same level of administrative hierarchies. Under that definition US states are the same as German bundesländer, French regions, Canadian provinces etc. even though their political influence and internal organzisation is wildly different. There is a lot of software around that works under the assumption that US states (and the equivalents in other countries) can be found at admin_level=4. The current admin level hierarchy is not perfect but it works for most practical applications. Please don't break it. If you need to have a more find-grained distinction on how the administrative units are organised, I suggest introducing a new tag instead of changing the meaning of a well-established one. Kind regards Sarah [1] http://wiki.openstreetmap.org/wiki/Admin_level#admin_level ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Hi, On Sun, Nov 09, 2014 at 10:33:58AM -0500, Richard Welty wrote: 1) the Census Bureau has an area based version of zip codes (postal codes to the non-US types) called ZCTA. it is not a complete representation, it covers about 30,000 of the 50,000 unique zip codes, but it covers all the ones that can be reasonably envisioned as areas. Nominatim is already using a version of the ZCTA data as an additional source. I know there are some bad errors in there preceisly because it seems that US zip codes don't really cover areas. The search allows a certain degree of fuzziness by accepting all nearby zip codes but that is really not good enough. 2) missing from ZCTA is the mapping from zip codes to postal city as you call it. there is more to it than just a many-to-one mapping, which i'll address in a minute. 3) most of the US mappers are opposed to importing this into OSM for a couple of good reasons, i'm one of those opposed. I can see that there are good reasons not to import ZCTA. It is just an estimate after all. Until now I was under the impression that the postal cities are different than postcodes in that they are well defined areas, i.e. I thought that they are much more similar to administrative boundaries just created by a different branch of the government. But from your mail, it sounds like they are much closer to the zip codes. 4) however, there is also a movement in the US mapping community towards having certain types of data kept out of the core OSM database, including various types of admin boundaries. there are two projects looking at admin boundaries in this manner; i'm working on one of them. 5) so if we could 1) come up with the ZCTA-City mappings and 2) provide them in a convenient external database for use by geocoders, is this something that might reasonably be made use of in Nominatim? i've been considering what a project to crowdsource the zip-city mappings for the US might look like. currently the data exists in OSM to handle about 4% of the mappings, but a maproulette style challenge might get us a lot of the rest. as for that many to one mapping that isn't, basically, for each zip code there is a primary city and potentially a number of secondary cities. the primary city is the city name of the post office that serves the routes; the secondary cities are generally traditional place names within the delivery area; for example, for years i lived in the Lansingburgh neighborhood of Troy NY, and the post office would deliver mail for either city name. any effort to crowd source this data would need to take care of that detail. If I understand you right then the 'secondary cities' are the actual cities/towns/villages already mapped as either place nodes or administrative boundaries. Those are already used by Nominatim. So it seems the primary cities are what I was thinking of when referring to postal cities and they can actually be inferred from the postcode. If that is right, it should be somehow possible to add that concept to Nominatim. I'd have to give it a bit of thought. Sarah ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Hi, On Sat, Nov 08, 2014 at 02:05:44AM -0600, Toby Murray wrote: Nominatim actually does not correctly use addr:city. You are correct in that it does assume a better match between physical border and postal city address. What happens is it actually puts city information on *roads* based on boundary relations and place=* nodes. Then it links individual address points to the roads. The addr:city tags on POIs and building outlines is actually completely ignored. This leads to things like this address not being found if you search for it in Manhattan, KS: https://www.openstreetmap.org/node/2209430502 On the other hand, this one on the next street over is found because I added an addr:city tag to the road: https://www.openstreetmap.org/node/2209427353 road: https://www.openstreetmap.org/way/13226787 I consider this to be a nominatim bug and haven't attempted to do a mass tagging of roads with addr:city because I see this as essentially tagging for the renderer. Well, agreed that Nominatim still misses the feature to mix in addr:* tags. It is somewhere on the todo list. To be honest, I'm not very motivated to fix it for the sake of US postal towns because I'm not yet convinced that the addr:city tag is the right solution for that concept. Postal towns are by all technical means areas and you should really consider tagging them as such. Let me just outline why addr:city is difficult from a point of view of searching. Assume Nominatim would handle addr:city correctly. That would alow you to find '6001 Stony Brook Drive, Manhattan'. But what about 'Stone Brook Drive, Manhattan'. I expect you would want to be able to find that too? That would only work if you added addr:city to the road as well or Nominatim added some means to infer from the addresses that the road is postal code-wise in Manhattan. It gets even more difficult for the addresses that have not yet been mapped. If there are addr:city tags on addresses in other streets nearby, then some dark magic might still guess the expected postal town correctly but it still means you need to add some addresses first. Any tagging schema that implies that much guessing really should be reconsidered. Postal towns is really a concept that wasn't taken into account when the Karlsruhe address schema was developped and IMHO doesn't really fit. I'd really like to see some discussion in the US community about how it can be tagged including considering the possibility to come up with a brand new way of tagging it. If you then come to the conclusion that addr:city is still the best way to go, so be it. But I'd be far more happy to support something in Nominatim that fits exactly the US situation than hack some European tagging system until it hopefully gives the right result most of the time. Kind regards Sarah (your friendly nominatim maintainer) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
