Talk:Oxford

From OpenStreetMap Wiki
Jump to: navigation, search

Completeness

I've marked Barton / Risinghurst as done, although I've only been responsible for a small chunk of it. It certainly looks done, but there's always the possibility that one of the other mappers is aware of (say) missing footpaths that they were going to come back to. If so, please feel free to revert. This is the age old problem of OSM not having any way to say 'I declare this region done' from within the map itself... --User:Mattwestcott 21:54, January 12, 2008

I'm wondering if we should get some QualityStreetMap data entered for Oxford(shire) as part of a rolling QA and checking programme. Not sure how we'd organise it, but we could use it to give a focus to the checking process. Maybe start at [1] and tag up each phase of map blitz? --achadwick 14:20, 24 June 2011 (BST)

Non-college University buildings

Resolved: Tag them as amenity=university

How should we tag non-college University areas like the science site, OCIS or the Old Road Campus? --achadwick 01:40, 8 March 2008 (UTC)

amenity=university is the global tag for this sort of thing. It looks like locally we're using learning= to distinguish oxford_colleges, so lets stick with that. I'd suggest learning=oxford_department but I'm open to suggestions. Socks 10:24, 7 May 2008 (UTC)
Should that apply to Brookes halls of residence? There's quite a few on my commute and in the Headington/Marston Rd area. Right now, they're just getting dressed up in landuse=residential, separated and `operator=Oxford Brookes University` in some cases. --achadwick 10:06, 16 May 2008 (UTC)

Bus stops

Resolved: There was a NaPTAN import as well. Please merge old and new stops together where you see duplicates. --achadwick 14:11, 24 June 2011 (BST)

Let's add these, and be bold about using new tags to do it. I'll try to document the conventions I've been using so far. --achadwick 16:13, 19 April 2008 (UTC)

My impression was that most people had settled placing bus stop nodes off the side of the way. Let's have that discussion on the Tag:highway=bus_stop page (or its talk page) -- Harry Wood 22:32, 15 May 2008 (UTC)
That scheme makes sense to me too, provided that a scheme for representing routes and associating stops with the roads they serve in a clean fashion emerges. I'm not overly attached to what is essentially a scheme for making the notes and gathering the information in a structured-ish fashion. I've moved the scheme to Talk:Tag:highway=bus_stop so it can see more light. --achadwick 10:37, 16 May 2008 (UTC)

How much separation is right?

Resolved: Discussion here pretty much petered out, but we seem to have settled on setting college etc. areas back from the central way of the road they abut. Makes more sense with better imagery now, too. --achadwick 14:09, 24 June 2011 (BST)

User:Imrehg wrote:

  • Use proper separation where areas share segments with neighboring streets and structures. For examle:
    • Many colleges (St Peters, Pembroke, Worcester, Nuffield, Lincoln, Balliol, Christ Church, etc...)

But how much separation is the right amount, and should ways or areas abut areas at all? I'm still slightly new here myself, but I've realised I've undergone a bit of an evolution in how I make areas. Currently I'm tending towards some self-imposed rules:

  1. If there's unobstructed access (no walls, hedges, fences) from any part of a Way into an Area, or from one Area into the next, then it's OK to share an edge. Representing access is a Good Thing.
  2. If you'd have to cross some sort of obstructing feature to get there, then separate. Place points to match up with the ground, using properly aligned yahoo_imagery if available.
  3. If an area would share all of its edge segments with other features, then make a free corner at the edge to allow editor software to select the Area more easily.

But for practical reasons and to allow other mappers to have a say, these days I try to separate all areas from other objects at first. We can fix it up later to say more about physical access. It's more important to get roads joined up first, if making good data for automated routing algorithms is your thing.

Yes, this is more or less what I meant. Colleges usually have fences and the road and college not actually share the physical space as a shared edge would suggest. But for example just walking off the pavement you walk into a park, then the sharing is probably makes sense. I only noted this, because it is quite annoying at the moment, to make out where the roads are and where the colleges. (and I don't mean that my approach is any better than someone else's, just want to make a more readable map) --Imrehg 12:33, 27 April 2008 (UTC)
I disagree - trying to represent access conditions by gaps between ways and areas is poor data. If the college comes right up to the street (and the highway= tagged way represents the whole street, road, pavement etc), then they should share nodes - if there is a gap between the street and the college, then we need to tag this area with what it is used for. The access needs to be represented not by artificial gaps in the data, but with proper tagging of boundaries, and perhaps a new relation proposal. Until there is global consensus on how to tag areas like this, please don't undo the hard work that has gone into creating areas that share the nodes of the streets that define them. Socks 10:24, 7 May 2008 (UTC)
I started a forum conversation about this here. Please join and let's see what people think... I would definitely vote for separation for much easier editing and I don't really think it is not worse data to separate them, then to say: the colleges and the road are not really occupying the same physical space. Anyway, I don't want to mess up other people's work, so hope this can be settled soon. Cheers! --Imrehg 12:18, 7 May 2008 (UTC)
> areas that share the nodes of the streets that define them --User:Socks
The problem of course is that you don't know how wide a road will be rendered. They have a non-zero width in any rendering, and are non-zero width in reality, but beyond that you can only speculate based on the class of highway and the number of lanes.
The lines making areas are different. They have zero real-world width, and so can be used to unambiguously represent an areas. So it's better data for areas if the points directly correspond 1:1 with physical coordinates - Christchurch college's façade doesn't really project 15m or more into the roadway and terminate at the centre line of St Aldates! If you think the edge of the road somehow bounds or restricts the edge of the college in the data itself, then you are mistaken and you might be guilty of mapping for the renderer. --achadwick 14:03, 8 May 2008 (UTC)
> trying to represent access conditions by gaps between ways and areas is poor data. --User:Socks
I'm entirely unsure about this access stuff, tbh. It might be better to represent the sequence centreline-carriageway-pavement-wallwithgateway-park for example as a short perpendicular footway, ---- below:
   |   |PPPPP     Where | and | are highway and park boundary
   +---GPPPPP           + and G are just nodes, the latter tagged as a gate
   |   |PPPPP       and  PPPPPP is the body of the Park area
But as there's no way of tagging part of an area boundary, and no way of tagging walls it's all a bit moot right now. I'm prepared to concede access can't really be represented between ways and areas very effectively right now.
--achadwick 14:03, 8 May 2008 (UTC)
> please don't undo the hard work that has gone into creating areas that share the nodes of the streets that define them --User:Socks
Don't worry, you've done tons of work on this and I shan't touch the data you've added until some consensus emerges. Besides, I'm mostly working on sketching in landuse=* areas and parks out in the suburbs right now: trying to keep ways separate from areas, but abutting some areas if one area really does bleed into the next, or is separated by a mere wall or a hedge. --achadwick 14:03, 8 May 2008 (UTC)

Physical access also means accessibility, e.g. for wheelchairs. --Lulu-Ann 08:43, 6 March 2009 (UTC)