I’ve come across a case in Rainworth which I’m not sure how to resolve.
The residential area boundary covers what locally is known as Rainworth Village/Rainworth.
However, the residential housing has expanded and leaves the Rainworth authority area, cutting into the Mansfield Authority. It is all attached to Rainworth and, locally/colloquially, it is still considered Rainworth.
However, if using something like osmAnd for navigation, searching for an address In this area that’s expanded into the Mansfield Authority area in Rainworth will not work, because that area technically comes under Mansfield, not Rainworth. People even give there address as Rainworth and mail routes there correctly.
Is it not all Mansfield (NG21) as the addr:city, with Rainworth as an addr:suburb? From a quick stare I can see that Rainworth Parish doesn’t cover the whole village but that’s not relevant to an address (you could draw the authority area as a polygon though).
looking at the map this village is a little messy authority-wise. Most of Rainworth comes under the Newark and Sherwood level 8 authority. The bit that’s entering into the Mansfield Authority Zone comes under the Mansfield Level 8 Authority. The Rainworth level 10 parish boundarie follow that of the Newark and Sherwood Boundary edge.
This creates a situation where bureaucratically, the village is under three authoritie boundaries, part under Newark and Sherwood, within the Rainworth Parish. Searching for an address to anywhere in this area would work as expected. but the part that’s expanded out comes under the Mansfield/Mansfield and Woodhouse Authority Zone, And searching for a street in the area in question within Rainworth doesn’t work.
The locals and people in general referred to it all as Rainworth however, and signage coming off the A617 roundabout onto the B6020 says Rainworth village. While technically within Mansfield, the village is detached from Mansfield itself and no normal person would refer to anything in this area as being part of Mansfield.
This mainly becomes a problem when getting a computer to route correctly to this area, when the code meets how people would generally search for an address. if someone is looking for a street in Rainworth, say, “Leeway Road, Rainworth.” the code falls over itself because, logically, no such street exists within the Rainworth boundary, so you get “No result found”. “Leeway Road, Mansfield.” does however produce a result.
I’m just wondering if there’s a best practice to deal with this sort of edge case, So when people search how they normally would, without concerns of bureaucratic boundary technicalities, They’ll actually get a result they expect.
The fundamental problem is that there are numerous hierarchies that could be used to define where something is - see previous discussions like this one.
I can think of at least 3 for Rainworth - the local “sense of place” one (I’d agree that Rainworth is very distinct from Mansfield there); the postal one (the old post town was Mansfield where you are, but you’ll see old postal addresses with Newark in as you move east**), and the “admin authority” one - unparishedMansfield, parished Newark and Sherwood etc.
I’m not actually sure what OsmAnd uses for address search, but whichever hierarchy it chose someone would think it was wrong. The search box on osm.org uses Nominatim. See e.g. here and here for examples from Rainworth. The place node of Rainworth is in OSM as the “admin centre” of Rainworth civil parish (which is part of, but not all of, the village of Rainworth). I suspect that that is what is confusing Nominatim to think that the western end of the village is not “in Rainworth”.
** Many years ago, before Google maps because near ubiquitous for car routing and when sat-nav phone apps were a very new thing, for the company I worked for I used to test new ones with addresses around there - Blidworth, Edingley, etc. The ones that just said “Street Name, Newark” (based on the old post town) were not recommended.
It seems like an unused less authoritative slot just sitting there, that could be used to fix these types of edge cases.
It could be used to define a “place/community”, to denote a non-authoritative but rational boundary around an area, as being agreed upon as being one place, despite being bisected by antiquated and irrational parish and authority boundary lines.
This allows things like the level 8 and 10 boundary lines to be correct in terms of how authorities definitive maps would have them drawn out, but also give a way for people to correct irrationality’s that arise through expanding localitys crossing authority borders.
People in the day-to-day do not care about bureaucratic boundary distinction when looking for somewhere. They just know it’s a street in a “place”. If someone looks at a map and it’s clear that there is a blob with a name, separate from another blob with a name, one would rationally say it has a sense of placiness.
Using admin_level 11 to define this can help make search more friendly.
Because boundary=administrative is for mapping administrative boundaries. If it no longer serves an administrative function then it doesn’t really belong in any admin_level for that tag.
boundary=traditional seems to be in use for ceremonial counties and boundary=historic is documented too, but most old boundaries belong more in OHM than OSM.
Nearly - this is the traditional county of Yorkshire (still marked and signposted in plenty of places) and this is the North Riding of that. The corresponding ceremonial county is North Yorkshire. Neither correspond exactly to modern admin boundaries but they do (in most of Yorkshire at least) correspond better to people’s “sense of place”. Neither would help with Rainworth of course - that would need a woolly extrapolation from the current Rainworth node, rather than relying on the civil parish.
As an experiment I did try feeding Nominatim (the geocoder on the osm.org site) just place, not admin_level, but the results were not good.
The same disconnect occurs in a number of countries. This doesn’t mean it’s a great idea to arbitrarily “fill” an admin_level=* slot with something non-administrative just because it’s available. Some countries have developed statistical area schemes that approximate informal place names. These could serve as an alternative, but we’d have to be careful about not jumping to conclusions about their suitability.
In principle, a place boundary can encompass the informal extent of the place name. You’d refine boundary=place with a place=* tag, which geocoders would pick up. However, Nominatim and probably others make some assumptions about how certain place=* values relate to certain admin_level=* values on other relations, so the results may not be perfect in practice.
I think @Ad-Man-Gamer’s original issue was that people using OSM data to provide search results may not find places that don’t align with administrative boundaries. I think the only realistic solution in OSM at the moment, is to ensure that the postal addresses are properly tagged on as many objects as possible in those areas. i.e. make sure POIs and properties that are within what people tjhink of as “Rainworth” have an appropriate addr:* tag with the value of “Rainworth”. It’s should then be possible for downstream data users to figure out that these places are indeed in somewhere called “Rainworth”, regardless of which side of any administrative boundaries they happen to lie
That kind of approach was suggested** at SOTM-EU for “identifying place areas”, using Naptan place information on bus stops. Compare for example here (in “Mansfield” admin area) and here (in Rainworth admin area). Not all Naptan fields are in OSM, so I’m using bustimes.org as a proxy to show what data is there.
It’s likely not an option for Nominatim on osm.org, but it’d be an interesting winter project for someone…
This is the approach we’ve been trying to facilitate in the U.S. as well. Unfortunately I don’t know of any geocoder that uses these tags as a substitute for administrative boundaries or place areas yet, but I still think this is the best way to get a handle on something that’s inherently fuzzy otherwise.
The villages of Rainworth and Blidworth both appear to be entirely within the NG21 0 postcode sector, which is in the post town of Mansfield.
I’d be inclined to complete the addresses in Rainworth with addr:suburb=Rainworth and addr:city=Mansfield. However, not everyone agrees with using the post town as the “city” and I don’t know what local mappers prefer.
Nominatim does use the addr:* tags for the object itself. Searching for them always works, display only if there is a place node nearby that fits the tag.
Just to say, is_in:* tags are also still supported. Sometimes they may be more appropriate when the postal city and the city of what everybody thinks it is deviate. Or when you want to add something to a non-address.
Sorry, I did not mean to intend to suggest to use a tag for something it’s not intended for. But I assure you the suggestion was not arbitrary.
admin_level=11 appears to already be in use for this kind of purpose in 3 countries acording to the Wiki, So it seemed like it was something already being tested out.
China = (Natural) Village / Group (Neibourhood)
Poland = boundaries for neighborhoods
Thailand = Community
Neighborhoods can be administrative or quasi-administrative boundaries, depending on the country (and in some countries, depending on the city). But from your description, it sounds like these boundaries wouldn’t resemble administrative boundaries at all.