-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl Newman wrote: > On Mon, Aug 25, 2008 at 3:34 PM, Mark Williams <[EMAIL PROTECTED]>wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> robin paulson wrote: >>> Rory McCann wrote: >>>> Gervase Markham wrote: >>>>> What's current tagging best practice with things which are to the left >>>>> or the right of a way (e.g. bus stops)? >>>>> >>>>> A nearly-approved proposal for a canal-side object has been objected to >>>>> by someone who thinks that the tag should be on a node which is part of >>>>> the canal rather than next to it, with left/right indicated as part of >>>>> the tag key name. >>>>> http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring >>>>> >>>>> Do we do that for any other tags? Do we have highway:left=bus_stop? >>>>> >>>>> Gerv >>>> Personally I add the node to left of the way, not as part of the way. I >>>> believe the OSM theory is that the way represents the middle of the >>>> road. So things like mini-roundabounds and traffic lights are part of >>>> the way (ie road), but a bus stop is off to the side of the road. >>> the problem with this is that 'bus stop' (and canal mooring, etc,) >>> implies a place where the bus stops, which is on the road. >>> >>> the fact the bus shelter, or sign, or bench, is some distance off to the >>> side of the road shouldn't matter - the bus itself stops on the road, so >>> the node imo should be part of the way >>> >>> if the bus stop is off to the side of the road, i.e. not connected to >>> it, then the bus can't physically get to it, which seems very wrong >>> >>> or, consider from the pedestrian's point-of-view: >>> it is assumed for all roads except motorways and where explicitly >>> stated, that there is foot=yes access. in which case, the >>> footpath/sidewalk/pavement is therefore part of the way which represents >>> the road; we don't draw a separate way off to one side, running >>> parallel. the bus stop must be on the footpath for the pedestrian to be >>> able to walk up to it, so again it must be part of the way >>> >>> this problem is i think muddled by the fact we represent an area (a >>> road) with a linear object (a way), which theoretically has zero width, >>> so the natural step from this is to say: >>> 'the way represents the centre of the road, and the bus stop/canal >>> mooring is not in the centre of the road, it's at the side of the road, >>> so I'll put it to one side of the way' >>> >>> as for placing the node to one side of the way in order to get the icon >>> to be placed correctly, this sounds a lot like 'tagging for the renderer' >>> >> I disagree with this view. >> Do you tag post boxes as way nodes? Shops? Telephones? >> No... >> So why bus stops? They aren't in the road. They are sites on the side, >> like all of the above. It makes no sense to tag them as way objects. >> >> I have seen the arguments about knowing which way they belong to; IMHO >> this is specious, no bus company works by looking at OSM to see where to >> route their buses, but a map user may well want to know just where the >> bus stop is - Anyone looking at a map of where they are who doesn't know >> which side they drive, is in trouble. The same goes for any navigation >> software. >> >> It really isn't hard to link from bus-stops as points to nearby ways - >> check out all the routing apps, not many need a hard node ID or way ID >> to commence from / get to - they find a nearby way from a lat/long. If >> Gosmore can do it, why not any other app? >> >> It just introduces a whole load of hassle working out which bus stop >> goes in which direction, sticking it in the middle of the road. It looks >> stupid in the renderers for a very good reason. >> >> My 2p, but I don't want this to look like everyone thinks that way nodes >> are good.. >> >> Mark >> > > If you happen to know exactly which nodes (which are not part of the way) > are your start and end points, then routers can deal with that. If you want > to know which bus stops you will pass while traveling along a way, that's a > much more difficult problem if the nodes are not somehow topologically > associated with the way. It's a more serious problem with house numbers > because the data volume is so much higher (many more house numbers than bus > stops), which makes it even more important to associate a number with a way > (and not by using the street name--that's not topological, is subject to > typos and is difficult to validate automatically). > > Karl >
Sorry? I don't have to specify a node for several of the routers, just a coordinate. Therefore I don't have to "happen to know" which node to go from. Equally, if I'm using a map to navigate I can see which POI's I pass, else (if I care) I can get a list by post-processing the route to see what's nearby - though I don't see that I'm likely to [care]. If the bus stops are tied to a bus route or a way by a relation, then it's trivial; especially compared to the difficulty of working out which bus stop to walk to when two are in the middle of the road, 200 yards apart. Is 'mapping for renderers' any worse than 'mapping for routers'? Step back from the "we're going to use it for routing busses" approach a moment; a fair few users may wish to print a map, so the renderers need to do this right. I will prefer to see the bus-stops pass on the sat-nav map as reference as I drive by them. I might like warning of busses likelihood of stopping. My main driver on this is that they are roadside features, not highway features. As I said, like pubs, postoffices, etc. This is the real world, mapping what's on the ground, bus stops are not like mini-roundabouts or traffic lights. Finally, yes I think the above is right for house numbers as well. My house is next to the way; not even on the implied footpath, it's an off-road feature. I think this is true of most... Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIs6SdJfMmcSPNh94RAtKKAKCWb3dVNLXlKD1ppqWPzKV6w5N+bACghFHc OEBJY3AxyXwJvuxYBNHvyig= =gvNv -----END PGP SIGNATURE----- _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
