Oxford/Boundary and area revamp
It would be good if all the wards, civil parishes, communities, organisational subdivisions and other areas within the city had corresponding areas: the newly revamped namefinder will like these, and having them done in a consistent fashion will make the data more useful.
- place=city one, obviously. Uses is_in=*.
- place=suburb very common
- place=village places like Iffley, which have been wholly consumed by the city but which still have their own identity
- place=locality one local community, very recent. Hey, it renders!
- place=islet recent (and better than island). For tiny little islands made by the rivers' courses.
In addition there is the OXFD pay scale area NaPTAN import, the limit of the Yahoo! aerial imagery coverage , and an enormous number of college grounds and sports fields. Not to mention many commercial and residential areas (whose individual boundaries are often chosen for editing convenience; in other words, don't rely on current residential areas unless they have a name or something).created by the
Where do we go from here?
- Decide which schemas to use and document properly.
- Hierarchy strata
- Update data; divide the city up
- Any levels of hierarchy? Perhaps sub-pages on the wiki for each of the major ones
- Fallout and fixups: re-express the completeness charts and to-do lists in terms of the new map data rather than the (completely arbitrary) cake-slice approach
Potential data sources
- Wikipedia , which might contain reusable *cough* cleanroomed data.
- Local knowledge  would be one very good way of gathering it. Ideal for "what's this area called?" questions.
- Community noticeboards often have a parish or community name carved into the wooden surround (need a photo here).
- The city council, for the official electoral ward stuff. They seem to use a 2-level hierarchy: . Perhaps some sort of release can be arranged?
- OOC stuff from libraries, records offices; note that the official boundaries are likely to have changed over time.
- Local sites, list here:   .
- Postcodes, via tagged postboxes and ? Note that this doesn't always match up with non-Royal-Mail geography.
What's the best way of encoding this? There are a couple of documented approaches elsewhere:
- Use boundary=civil and admin_level=*
- Use place=* in mode
- Pros: largely an extension of what we do already. Simpler to get data (go out and look, ask people!)
- Cons: we probably have to be a bit more careful about the levels we use; doesn't map neatly to administrative levels
- Notes: should probably use the suffixed form of is_in=* too.
No reason not to adopt both: I think the former would be a better schema for the official stuff and the latter for more informal names and local communities and estates which might have rather fuzzier edges.
Hierarchy for places
Do we have a hierarchy, and if so what is it? One possibility for the place=* axis:
- city "Oxford" → suburb "Cowley" → locality "Lye Valley"
- Use an appropriate is_in chain on each central and use the normal place_name/place construction to relate (ho, ho) the area to the node. Or should it be both. Or the other way round?
- On trusting data: Lye Valley has Headington postcodes, but is electorally within the Cowley area, according to Headington.org.uk
- On the ground, localities might only be identifiable by "parish"-style wooden noticeboards with the name carved in. They /might/ refer to electoral wards, to little civic hub with some shops in it, or just to the street they're on. If the board name has the same name as the street it's physically located on, it might be a little pointless to map it unless you know there's an electoral ward or a civil parish or something also having that name (that you might want to be visible when zoomed out a bit)
You also have villages such as Wolvercote and Iffley that are part of the city and within the city boundaries that have their own identity:
Oddities like the Bartlemas Conservation Area that don't (yet!) have anyone living in them should probably get tagged as a locality in the truest sense and slotted into the hierarchy wherever they make most sense. Assuming no other tag is of any help.