Re: [Tagging] parking
Roy Wallace wrote: How should a parking lot be tagged, that is provided for customers, e.g. at a restaurant, or retail business? It may be signed as such (e.g. Customers only), or may not. I would add access=permissive. You can a note=* tag to describe it in more detail if you want. That way if a more precise tagging system emerges then hopefully your note will assist later. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] parking
Matthias Julius li...@julius-net.net writes: Chris Hill o...@raggedred.net writes: Roy Wallace wrote: How should a parking lot be tagged, that is provided for customers, e.g. at a restaurant, or retail business? It may be signed as such (e.g. Customers only), or may not. I would add access=permissive. You can a note=* tag to describe it in more detail if you want. That way if a more precise tagging system emerges then hopefully your note will assist later. access=permissive does not imply any restriction on who can park there. access=destination was also suggested, but IMO it expresses You may enter the parking lot if you plan to park here. I think access=destination is natural and expresses concisely you can park here if you are visiting an associated business. streets with access=destination are really you can drive here if you are visting someplace near it - even if you typically park in someone's driveway off the access=destination way. pgpzWbsfyqi4B.pgp Description: PGP signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] More cycleway=* values needed
On 08/12/2009, at 11.17, Steve Bennett wrote: Given this, it would be fair to say that the meaning of cycleway=track is a two-way copenhagen-style bike lane. If copenhagen-style refers to the danish capital, this is something of a misnomer; there are practically _always_ a one-way path in each side of the street in Copenhagen and the rest of Denmark. Two-way cycleways are quite rare. Cheers, Morten ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] parking
Greg Troxel wrote: I think access=destination is natural and expresses concisely you can park here if you are visiting an associated business. streets with access=destination are really you can drive here if you are visting someplace near it - even if you typically park in someone's driveway off the access=destination way. That sounds good to me, as well. If you want to tag a more permissive drive through, i.e., you can drive through here, but don't park unless you are visiting an associated business, then you can add a service road through the parking lot. However, I don't think it's worth trying to tag any restrictions on those two or three slots in front of a shop in a strip shopping center that say parking for this shop only. -- Randy ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] parking
On Wed, Dec 9, 2009 at 7:13 AM, Randy rwtnospam-new...@yahoo.com wrote: I think access=destination is natural and expresses concisely you can park here if you are visiting an associated business. ... That sounds good to me, as well. So... access=destination seems to have some support. My issue is that its use doesn't really reflect the wiki definition - which, at the moment, is only really explained in relation to highways. At the moment, access=destination is defined as the public has right of access only if this is the only road to your destination. For access=destination to be extended to parking areas, I think this would need to be changed to something like: the public may access/use this entity only if it is necessary to do so in order to get to your destination. Is this sufficient? Secondly, Peter asked How should we tag a private corporate employee car park ... where there are staff car parks and patient car pars and they are different. This is a good point, and it can't be expressed with access=destination. This is another reason why I'm still leaning towards introducing parking=*, in which case the carpark for staff would be parking=staff and for patients, parking=customer. Thoughts? Change the definition of access=destination or introduce parking=*? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle=no
On Wed, Dec 9, 2009 at 3:30 AM, Mike Harris mik...@googlemail.com wrote: ... On the last point - could we even deprecate designated= - I find it confusing and redundant and always use designation = (see wiki pages) - but maybe this is wrong? Well, we could deprecate a lot of things - it just depends on what we want to be able to tag, and how we choose to do it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Wed, Dec 9, 2009 at 2:33 AM, Steve Bennett stevag...@gmail.com wrote: Information about tag support is a *good* thing, not a bad one. I now realise that Mapnik doesn't recognise *any* sport=* tags, but that's not going to stop me using them. But it will make me be careful to always use it with a tag that it *does* support as well. See how this is beneficial? I don't see how this is beneficial. As others have said, it just encourages tagging for the *current implementation of* the renderer, as opposed to tagging with a long-term view. I strongly think taggers should not be influenced by the current implementation of a handful of renderers. This yes/no information may be beneficial, however, to those wanting to improve renderer style files, i.e. to see which features they have yet to consider rendering. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Tue, Dec 8, 2009 at 7:30 PM, Cartinus carti...@xs4all.nl wrote: On Tuesday 08 December 2009 17:53:33 Anthony wrote: Information about tag support is a *good* thing, not a bad one. I now realise that Mapnik doesn't recognise *any* sport=* tags, but that's not going to stop me using them. But it will make me be careful to always use it with a tag that it *does* support as well. See how this is beneficial? Actually, I think that's a good example of the harmfulness in tagging for a renderer. We shouldn't have redundant data in the database, at least when this is at all feasible. Wow, so now it is already harmfull to osm to know you have to map leisure=sports_centre|pitch|track|etc in addition to sport=* to have it show up with renderer X, but with renderer Y there would be no need for that. No, sorry for the confusion. The wiki is clear about sport=*: Since this is a non-physical tag it should be combined with one of these (physical) tags It has nothing to do with the renderer, though. In fact, the wiki specifically cautions you not to worry about the renderer: Though most of these tags are rendered when used stand-alone, a combination with a physical tag is strongly encouraged to avoid misunderstandings. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Wed, Dec 9, 2009 at 4:32 AM, Jochen Topf joc...@remote.org wrote: First comment though: Please, please start making a distinction between the rendering software (Mapnik) and the style file is uses and the map it creates, respectively. This is already problematic. It should not be called Mapnik-support, but something like Default OSM Map-support. We should come up with nice name for the default map. Sorry, you're absolutely right. The confusion arises from the fact that the Default OSM Mapnik layer on the main openstreetmap.org view is called Mapnik. It probably shouldn't be. Second comment: As always, its not that easy. You can't just read osm.xml. At least you have to take the osm2pgsql config into account. Also you probably Sure, can you give me a few pointers? I haven't got Mapnik or running. People can check it, improve it Well, improve the generation method. Hand tweaking would be the wrong approach. and get some experience about its usefulness. Just an idea: If you really want to check what the renderer renders and what not, how about creating a osm test file with all the different tags ins there, send it through the renderer and check whether the bitmap is empty. If it contains something in the right spot, you know the tag is supported. This is totally renderer and style agnostic reasonably easy to automate. Yes...but from what I gather, getting Mapnik installed locally is quite complex. Or maybe I'm confusing it with getting slippymap/tileserver installed. I'm new to all this. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] parking
2009/12/9 Randy rwtnospam-new...@yahoo.com: On further thought, while I'm OK with either approach, I think amenity=parking, parking=customer is a better way to go than bending access=destination to fit the issue. It seems a little closer to what seems to be a best practice in other areas. And, it does establish a structure for other potential parking restrictions, if they come up, such as parking=student parking=staff and parking=visitor at a college, Or even parking=A where only those with an A lot sticker are allowed. That may be a little too cryptic for a tag, but I think it makes the point. This would also set the system up for something like parking:max_time=1hr. Also things like Short term and Long term parking areas near airports, ferrys, etc. Max stay is good for marking how long you can stay, but it doesn't show that there is a minimum time (which some long term parks have). Also, parking areas for long vehicles only (trucks, buses, caravans etc), which are quite common at some of the bigger service stops/rest areas near here. I know at least one driver personally who keeps a special map tagged up with those around the country. Stephen ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Wed, Dec 9, 2009 at 9:09 AM, Roy Wallace waldo000...@gmail.com wrote: I don't see how this is beneficial. As others have said, it just encourages tagging for the *current implementation of* the renderer, as opposed to tagging with a long-term view. Ok, can someone point me to the policy that says don't tag for the renderer? I can't find it. It keeps being quoted like a fundamental axiom. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On 09/12/2009 01:27, Steve Bennett wrote: On Wed, Dec 9, 2009 at 9:09 AM, Roy Wallace waldo000...@gmail.com mailto:waldo000...@gmail.com wrote: I don't see how this is beneficial. As others have said, it just encourages tagging for the *current implementation of* the renderer, as opposed to tagging with a long-term view. Ok, can someone point me to the policy that says don't tag for the renderer? I can't find it. It keeps being quoted like a fundamental axiom. See these pages: http://wiki.openstreetmap.org/wiki/Good_practice http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer As that page says, its probably more acurrate to say Don't deliberately tag incorrectly for the renderer. Craig ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Wed, Dec 9, 2009 at 2:02 PM, Craig Wallace craig...@fastmail.fm wrote: See these pages: http://wiki.openstreetmap.org/wiki/Good_practice http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer As that page says, its probably more acurrate to say Don't deliberately tag incorrectly for the renderer. Whew, that's a relief. I would never suggest tagging doing that. Nor would listing the tags currently recognised by any renderer encourage anyone to do that. Incidentally: The following pages link to *Tagging for the rendererhttp://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer *: - Good practice http://wiki.openstreetmap.org/wiki/Good_practice (← linkshttp://wiki.openstreetmap.org/index.php?title=Special:WhatLinksHeretarget=Good_practice ) - Talk:Interstate Highways Relationshttp://wiki.openstreetmap.org/wiki/Talk:Interstate_Highways_Relations (← linkshttp://wiki.openstreetmap.org/index.php?title=Special:WhatLinksHeretarget=Talk:Interstate_Highways_Relations ) - RU:Good practice http://wiki.openstreetmap.org/wiki/RU:Good_practice (← linkshttp://wiki.openstreetmap.org/index.php?title=Special:WhatLinksHeretarget=RU:Good_practice ) - Talk:Proposed features/orchardhttp://wiki.openstreetmap.org/wiki/Talk:Proposed_features/orchard (← linkshttp://wiki.openstreetmap.org/index.php?title=Special:WhatLinksHeretarget=Talk:Proposed_features/orchard ) - Ja:Good practice http://wiki.openstreetmap.org/wiki/Ja:Good_practice (← linkshttp://wiki.openstreetmap.org/index.php?title=Special:WhatLinksHeretarget=Ja:Good_practice ) Could I politely suggest that more wiki linking is required? :) Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] More cycleway=* values needed
On Wed, Dec 9, 2009 at 5:43 AM, Morten Kjeldgaard m...@bioxray.dk wrote: On 08/12/2009, at 11.17, Steve Bennett wrote: Given this, it would be fair to say that the meaning of cycleway=track is a two-way copenhagen-style bike lane. If copenhagen-style refers to the danish capital, this is something of a misnomer; there are practically _always_ a one-way path in each side of the street in Copenhagen and the rest of Denmark. Two-way cycleways are quite rare. I was a bit unclear. copenhagen-style bike lane = single way by default. I was suggesting that cycleway=track, tagged on a road, would mean a *two-way* copenhagen-style bike lane, because cycleway=* is two-way by default, track= means segregated from other traffic, and that's what the logical combination of those two ideas would mean. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] More cycleway=* values needed
On Wed, Dec 9, 2009 at 9:59 AM, Richard Mann richard.mann.westoxf...@googlemail.com wrote: While we're about it, there's a few other potential values for cycleway (for interest mainly): cycleway=buslane (shared with buses) Has potential. cycleway=filterlane (explicitly shared with nearside-turning traffic) Has potential. cycleway=tight (nearside lane is shared with traffic and is 3.1m wide Two descriptive. Sounds awfully much like cycleway=no to me. cycleway=spacious (nearside lane is shared with traffic and is 3.7m wide, more if typical traffic speed is faster than 40kph) There's something here. If you look at: http://www.nearmap.com/?ll=-37.859974,145.16891z=21t=k This is Springvale Rd, in Melbourne's eastern suburbs. I'm told that that left lane (on the northbound side) is deliberately wider to cater for cyclists. It's not really a bike lane, but there is some benefit for cyclists there. cycleway=critical (nearside lane is shared with traffic and between tight and spacious) Nah. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle=no
On Wed, Dec 9, 2009 at 9:11 AM, Roy Wallace waldo000...@gmail.com wrote: On Wed, Dec 9, 2009 at 3:06 AM, Anthony o...@inbox.org wrote: On Tue, Dec 8, 2009 at 11:58 AM, Steve Bennett stevag...@gmail.com wrote: IMHO, it wouldn't be hard to make objective assessments if that's what we wanted to do. You could have suitability=: *None: surface physically cannot be ridden on, big boulders, trees etc. *Poor: Can be ridden on, but only by keen mountain bikers. Grass, very rough gravel, frequent steps etc. *Average: Generally smooth, but with enough obstacles that you would take a better way if you had the choice. Wide enough to ride, but not comfortably pass a pedestrian. *Good: Wide, smooth, few obstacles. Kerbs generally eliminated. *Excellent: Wide, very smooth, long stretches of several kilometres between any kind of obstacle. Cyclists can comfortably pass at speed. Forbidden to non-cyclists. Seems to all be covered by: http://wiki.openstreetmap.org/wiki/Key:smoothness http://wiki.openstreetmap.org/wiki/Key:surface http://wiki.openstreetmap.org/wiki/Key:width http://wiki.openstreetmap.org/wiki/Key:access Yes...but again, OpenStreetMap is a *map*, it's not just a collection of data. By all means, tag all this stuff, but higher-order interpretations of that data are what *mapping* is about. Ideally, we would not invent our own standards though, but apply existing ones. (Also, more pragmatically: bicycle_suitability:average is a lot easier to tag, and doesn't require marking up every time the surface changes from gravel to crushed limestone, or changes width from 1.6m to 1.4m. Using all those tags would be far too fine-grained.) Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle=no
On Wed, Dec 9, 2009 at 1:21 PM, Steve Bennett stevag...@gmail.com wrote: Yes...but again, OpenStreetMap is a *map*, it's not just a collection of data. I don't think this is necessarily true - or maybe I just don't know what you mean. It's a collection of meaningful data. The only thing that makes the OSM database like a map is the fact that the entities are associated with a latitude and longitude. By all means, tag all this stuff, but higher-order interpretations of that data are what *mapping* is about. Ideally, we would not invent our own standards though, but apply existing ones. It depends what you mean by mapping. Do you mean cartography? If so, I think that is the job of the user (e.g. renderer) moreso than the tagger. (Also, more pragmatically: bicycle_suitability:average is a lot easier to tag, and doesn't require marking up every time the surface changes from gravel to crushed limestone, or changes width from 1.6m to 1.4m. Using all those tags would be far too fine-grained.) Ok, sure, being easy to tag is good, but you have to weigh it up against the disadvantages, including not being directly verifiable. If you've done this and still come to the conclusion that bicycle_suitability is better, then go for it - write up a proposal and RFC :) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] A first step towards bringing the wiki and tool support closer together
On Wed, Dec 9, 2009 at 1:02 PM, Craig Wallace craig...@fastmail.fm wrote: See these pages: http://wiki.openstreetmap.org/wiki/Good_practice http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer As that page says, its probably more acurrate to say Don't deliberately tag incorrectly for the renderer. Yup, but to tag *correctly* for the renderer is simply to tag correctly. :P ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] parking
On Wed, Dec 9, 2009 at 1:02 PM, Steve Bennett stevag...@gmail.com wrote: How about this: parking=public (or no parking tag), presumably anyone can park here, perhaps at a small fee. parking=commercial: anyone can park here, it's a business. parking=customer: anyone using the services of an associated organisation can park. May require payment. parking=authorised: you can park here only if authorised: staff member, member of club, etc. Basically, you would need a prior arrangement. Hmm, I've just noticed that parking=* is already defined on the wiki as multi-storey, underground or surface (http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking). In that case maybe we should continue trying to bend access to fit the purpose, or aim for something more like: parking=multi-storey/underground/surface parking:who=public/customer/authorised Commercial doesn't fit here - equivalent to public. I'm not sure about parking:who... I think the goal is to give broadly useful information rather than to map all the subtle nuances. Yep. I wonder if there be some kind of parking=private for things like parking spaces near apartment buildings, or spots inside company grounds, but there may not be enough distinction against authorised. Good point. I'm not sure. I would think in this case you would maybe leave parking:who blank, and just use an appropriate access=* tag on the road/driveway leading to it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
