I think I copied someoneelses roundabout I think it was used as the roundabout might not have similar sence of class (primary, unclassified etc. I think also it was used by some software to enable that the special conditions of a roundabout were present and also I think it was used by some renderes to drow the spot as a special roundabout symbol, or it could be that I was moveing it for an incorrectly identified mini-roundabout which it wasn't signed or sized to be.originaly the roundabout between the Osney Lane and the A420 just a little way south was similar but although it began life signed as a new roundabout with a cyle bypass line defined in paint later received some mini-roundabout signs too to be confusing. I also looked at tag info and someone else defintly has been using the same tag combination as I haven't made more than 60 roundabouts! If highway=mini_roundabout is valued for several feature markings then highway= roundabout should be just as valid?

well maybe I'm looking at the roadscape and try to give meaning to the different areas that make it up so an area for the sidewalk, an area for the carageway an area for the central resveation, and so on and then I find I have these verges left over and so it just seems logical to call the highway=verge and then add sutible suface tags. I meen I could just call them landuse=grass and cop out but is that really what they should be or is it just lazy because we think most things will be happy with lots of tiny fields in the roads?
I could (I've done it before{though I'd improve them}) but should I? that's the question. afterall surface=grass, landuse=grass and landcover=grass can meen the same thing but should they be used for different situations instead?
It just feels a little that maybe they should espcilly if folks have trouble with multiple overlaping landuses in buildings (yes some did complain about it when a flat was over shop! but there system couldn't cope.)
I guess I'm two minds but maybe it's worth asking if I am doing the right thing with landuse=grass in unusal places?

What do you think? Should we have functional names for the parts of the road based on function and not surface type alone?

I also found more instances of vedge=*

I was feeling that landuse grass though works in a lot of renderings made less surface=grass when tags like osm.wiki/Proposed_features/landuse%3Dhighway & osm.wiki/Proposed_features/landcover are compeateing especialy when the surface could easily be the same highway feature with surface=tarmac, suface=asphalt, suface=cobbles etc its a sort of traffic island on the side of the road the fotway=sidewalkabuts staight onto front gardens and private driveways and front garden paths. I was trying to make a sence in the tagging that this is less of a field and really a verge. The highway architect used it to make the parking make sence and improve the apprance of the roadscape but in essence as a highway area it should be tagged similar to highway=verge.
What do think would work better especially if the whole set of vege sidewalk and carrageway gets a blanket landuse=highway as it ideally should?

ok managed to get back on today I tried fri but only had 10sec to close!

I've thought a lot about your comments and have the following possitive views and ideas:-

With regard to the spercific point about dealing with building outlines and addresses.
There seem to be others very intrested in basic trace outlineing and basic addressing. So I tend to let them have there way a lot. ..but then I come and use these as a basic starting point for refinement and detailing sorting out bay windows coloumns porches and other small building features. I look at garden gates paths hedges lawn and flowerbeds to give a nice look to end maps that want to use these features. I look for parking spaces and garaging (including details on markings nameings and owner details posted at the site). I try to flesh out yards, forecourts, driveways and other potentialy missed service roads. I look for still exsiting back alleys and footways that have benn more common then most maps and arial photos can show {think tree cover near back gardens linked with narrow passages close to buidings originaly filmed from a slight angle etc.} I cross referance with other sources to get a feal for how things have developed - which helps me interpert things i servey with a greater appretiation (so I can make sence of the scuby patches of no-mans land that you occasionaly see in places, and where owners are seeking greater rights to land than they actualy have).

I tand to focus on a workable patch till its mostly done and then move on until the entire map is complete. [but it might seem confused from this as I try to multiplex a lot of acitities to run at the same time so the edits look more scattered and half finished a lot {see my diary entry on the subject for some time back}.
I did have a focus on the "gleb-lands" at the western point of southpark about a year ago and spent a few months resuching, visting and compiling servey notes, several sessions at work drawing everything and continuing long into the evening after work too. I'd even been writting in the help qu.'s wiki system about area highways and used Wingfield street as a ilistrating example as I just done the sidewalks part of cross street and morrell Avenue ready for the ubern treesand grass borders along Morrell Avenue. I'd also compleated the carrageway that stops short in Wingfield street and begun on the parking options at the site. along with this most of the houses and other building on that block I'd drawn so I could add NPLG:UPRN's to all of them (involing canvusing bins on several bin-days).

Then osm.org/changeset/22641522 saw lots of the sidewalk areas important at the side of 77 St. Clements {yes I have stared at those fadeing house names for ages to work them out completly} removed along with other highway areas and address points with floor details for flats and seperated for gazzeter compilers (ok its sketchey at the moment but thier is a aimm to be able to have open-souce adderess lists available from this work and questions about it regulary come up in the help questions.

The deletions were done aledgedly on grounds of "style"!!!!!!

I was so upset that I abondoned work on inputing data about the 105 St Clements flats that I'd just surveyed and decided not to map that area anymore. only recently did I do the odd part of the north side morell ave, some house names in St clementsand some glaring omisions of nhs places etc. but I intend to skip this place mainly.

ok I said this was to be mainly positive so the good news is I focus on those buildings and address especialy tring to find hmo's and flat numbers [see indoor diray notes on this too]
===
Interior levels make sence when tring to work with buildings that have multiple addresses withen them (which is pretty common in oxford and especially so in the south east part I did a lot of work in) most shops have several domestic flats or bedsits a lot of small blocks of flats are common inthe new builds and even two surgeries in Manzil Way have few floors of flats on top. the shopping centres all have independant offices on the upper floors and two have schools and branches of goverment in them. So It stands to reason that I'd try to map these in a stacked indoor type approach: and if it was up to me then the land use tags would be overlapping all over the place. I think indoor tagging can bring clarity to the situation, though my efforts are thwated a lot by editor non-support for node stacking properly. Each layer is vertually mapped seperatly from the rest but a lot of verticle cueing occurs because of load bearing walls, stair and lift wells, and riser couboards.

Competitor Goggle has experiments of indoor and 3D mapping in oxford possibly inspired by when OSM is doing I can see them chaseing some of the featues I add sometimes which is intreasting. Bing seems to have abondoned vertical mapping accuracy at times to give useful "bird's-eye" at angle views that I use a lot (for being shapper and a good cueing transition from ground surveys).

===

"micomapping" is not potentially any more confusing to edit for the next person if take a good approach. Theres more going on so the detail level is higher and more things to be consider when you move stuff about.

editors can help improve things if they look out for vertical tags on features and try not mangle together features automaticly. Nodes at first waren't automaticly conected and this gave problems in the pas when people forgot to connect ways at junctions [messingup automated routers] so node auto mergeing became the standard but then people objected to stacking because there automerging editor didn't work with it and error checkers for missed nodes Said "That is wrong" assuming they were missed junctions. ..but the underlying database can take stacked features and indoor mapping makes them increasingly common. So this automerge is more of a problem than a solution and needs to become switchable. For novices editors could look out for verticle tags [like: level, roof:level, layer, alt, hight etc] and avoid blindingly auto merging those feature and there nodes especilly of course operators should have the option to make a merge as an edit but the editor should alert the operator about the tags and potentail problems. id online editer already has a new feature type filter system & JOSM has a less automated filter system {at least probably on the version about a few hundered behind the current that I last used a month ago!}

Before retagging if you're in id you are often offered basic help on the wiki
I think I'm probably writing too much but then it reflects that I thought too much too ;)

==

I think clearer standeds with logical extension options for unforseen situations is something that is very important {especialy for new people} {but also ways to guide older mappers to look at aggreed schema changes specially for les familer new feature details}.

as I try to make all my entries conform to the wiki (sometimes I even extend it for new tags I need to create - highway=monuvering_forecourt for instance):
but the wiki isn't oftern stable with new features common in micromapping so it's not uncommon to find multiple methods [great minds think a like -but don't always talk to each other quick enough]. ..and it gets worse when people "think" they know another right way that isn't even in the wiki and alter others work to reflect this.

The adage of not retagging stuff that isn't really wrong is a good one and common in a lot of the wiki pages. The problem is that contributers add stuff to the database and then make up automated search and styling sheets to look for specific tags they left in the data, So that the infomation is picked up for their gazzetters, on-line maps, poster renders, Geographic locators and router systems.
Now if people get into a habit of just changeing tags rather than actually suveying and correcting features that have real mistakes or things have altered at the site like new erections and shop changes. Then other contributers are going to find there work going missing from there well planed systems; which is likely to be just going to annoy more people than it aids?

ok I've written a lot and not in the odder it is on the page so I'll summate and end.

editors avoid alway automergeing when vertical tags used.
standerds for new features need to be diseminated to all quicker so we don't waste time redoing each others work rather than getting on adding more detail and corrections to the map.

and indoor areaisation micromapping and other recently novel areas of OSM need to be seen as part of the whole and not avoided topics by mappers as they will increasingly be appearing all over the map and not learning about how they work might make problem edits occur in future.

==

OSM is growing and detail improvements are spreading across the globe. Its going to be patchy for a while yet but if we all work to same "hymn-sheets" we will achive more faster.

I'll leave with the following patch I was asked to work on osm.org/changeset/32961073#map=19/49.84911/2.88818
this changeset is the second of two I did after local mappers wanted some help.

Hi, I think the placeing of Cowley and Temple Cowley are swaped by mistake. Temple Cowley is South-West of Cowley. Cowley lies on the hill side between the B480 and "the old road to cowley" Barracks Lane. Land lower to the south more into the flat river plane was subject to marshing, and flooding till the last centry or so.
Temple cowley is were a lot of the big retail developments are since the 1960's big redevelopment (later retail expanded when a factory closed across the road to the north in the new melenium.

thank you for the reply.
I think I sufer time contraints a lot which I think makes me more ancious when I spend so much effort on getting details right for people to make errors not because I'm wrong in the detail but they make asumption on limmited facts oftern its not so common but used to have at one time someone tailgating all my work that drove me crazy in the endas you could tell they didn't even check arial maps in editors by what they did but so as not too come over negitive espcially as a bell is tolling here and I'll be cut off midstream before the better part.

I like to be a detail-merchent mainnly because of the size of maps I make for the data. ie entrance to building maps and footways for pedestrians (like a cycle map but for wheelchairs ansd walkers.

I'll fin tommow.

Hi Socks,
I'm confused about the connection of adding node 3105547790 to way 305867452 which was originaly only with Way: 305867453. The confusion is that you can't reach node 3105547790 from way 305867452 without using Way: 305867453 or a ladder as they are on different floors! At this site I had begun to include the entrances to flats that have front doors built above each other so under the indoor convension it needs stacked nodeing. There's a lot of similar stcked nodeing for verticaly seperated entrances at the the CAB has this edit damaged the flooring of nodes and ways?

The system was breacking beneath me as I did the last parts of this it was difficlut over the session too.

Ok I out of time so I'll fiish up about the indoor problems and lugging a desktop to a public libary to be able to use josm when id and portlatch failed me will be tomorrows continuation.

Finally I've adopted a new highway tag that I explained in a wiki page before using in appropriate places.
this the highway=manoeuvring_forecourt that use for a place that is like a turning_circle, a parking_aisle (service), a driveway (service) and a yard but as it blends the other roles or is enclosed (unlike a parking_aisle (service)) it isn't clearly explaned by any other them individually, and as osm dosn't like me to dump multiple versions of the highway tag into one feature I developed a the new manoeuvring_forecourt to cover it. manoeuvring_forecourt's also oftern have implied parking and loading rules that can be better expressed on a map with some clear differntiation, so I made the wiki page and started to use it. Now I tought of making a type of service but I had thought if turning_circles get top level then so should manoeuvring_forecourt's.
Before you say they aren't supported the Humanitairian renderer dose support them as an all black feature. So they are recognised as a highway type.

next chunk:-
So prep the routeing line to give a currently blank(latter to be tagged-up) k-point and then adopt both the area=yes feature method and the area:highway tag system (that will learn to use more of when I look at more on street area details to enter)
this approach is in the wiki along side info on k-points see the links bounceing about oxford high street for more details on this.

After a lot of debate there seem to be two settled camps of thought on areaised highways entered into OSM (yes spent a lot of effort trying to the one true path but it isn't there in way I expected).

Some think they should be like other features that get an area=yes tag included to higlight they are area ways and not linear ways. While some think special tags should be used to more easily highlight the relationship between the midway routeing line and the areas by forming a new area:x style tag to form k=area:highway. Sometimes linked with this is the practice of K-nodeing witch which with the right rendering program can developed stop, giveway and simlar features markable on the road (I've been wondering how this works with advanced stop lines that allow bycycles to get to the front of the lights to turn easier accross the taffic flow when its slow or stopped (ithink the secret is in the cycle lane areaising like an L with two effective k-points of natually differing widths),
an example where I've prepared for this is at:-
osm.org/way/342095176#map=19/51.75492/-1.25387

on the crossroads just outside the King's Arms pub.

next chunk:-
I've foun it usefull to have the HGV Turning head clearly marked on maps as the concreate was originaly relaid with their need in mind, and it helps encorage lorries to use it rather than belive they will need to reverse for meny 100's of meters around tight bends (tighter since some awkward person mistook the road for a car park (originaly a banned process {delivary HGV's ruled}, then ignored by car parkers. Before being allowed in a semi-controled way)), and down a hill with children sometimes out playing too.

This is aspecially trure for those systems that don't render the areas well so not installing confidence into dispatch and drives alike.

next chunk:-
Now as I use the tags based on the infomation found out about the site: I may have some tags unused where infomation is not confirmed (that might get included when it is found).
...and as the tags are chosen by purpose (not just variation) they may have the same or different values based on real-world usages, of them.

next chunk:-
finally I may have access to internal or customer faceing records that carry a referance number or other text string or symbols. These I add to OSM in a normal ref tag; as is normal tag usage.

ok next chunk:-
I found some garages such as most Oxford city gargages have postal addresses, oftern with a variation to the name phisicaly on the garage (to avoid confusion with dwellings with similar numbers or names).

So where I can find these I add the appropriate regular address tags, including a addr:housename or addr:housenumber depending which looks most appropriate for the idividual garage [or bay of they ever come up the same way].

next chunk:-
I use name correctly to give things phisicaly marked or written on the garages (in the same way I use the name tag when reley legend or symbols on parking spots {such as Owens Way (Way: ♿ (342095176)) })

A data sorter or renderer can filiter away these names if not requied by selecting out names from garage or parking space features.
There are different common renders that do support named garages while others choose not to use them.

next chunk:-
I use three fields to carry the name or number or assoiciated marks of garages and referances to teach OSM about the offical groupings and blocks used by operators to manage there garages stocks {this was to allow better data services on to the back processing of annotated website maps for customers to pick and find new garages to rent}

see:-
http://www.oxford.gov.uk/PageRender/decH/GarageLocationsSouthfieldParkandStClements.htm
http://www.oxford.gov.uk/PageRender/decH/Garages_to_rent_occw.htm
and
https://www.google.com/maps/d/viewer?mid=z0nFLiwzFNIc.kVKYCvg26Rew&msa=0&ll=51.754028,-1.230125&spn=0.103077,0.220757

next chunk:-
I did specific site surveys to collect the marks, numbers and and names on all the garages I've mannaged to put into osm plus other that ran out of time for.