Re: [Tagging] [OSM-talk] Tagging wide steps (tribune / terrace)
On Tue, Jun 8, 2010 at 7:09 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: actually this is not yet incorporated in the area proposal, that's why you might be confused, but it could be done with it. So just to summarise, you would have a relation: type=area highway=steps step_count=15 (already documented on the wiki) with way members: role=lower, role=upper, and two role=lateral (I don't think these values need to be prefixed with steps:) Fair enough. The tricky part is the assumption of parallel interpolated lines from the lower to the upper way. Parallel probably isn't the right word, at is usually won't be possible - some fancy maths and approximation would be necessary to render the individual steps properly, in most cases. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Tagging wide steps (tribune / terrace)
On Mon, Jun 7, 2010 at 10:46 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: To do this explicitly, you'd probably want to map each step individually (as a curved way), you would do this following the area-proposal, but you would probably reduce it from each step to each first and last step of a continuity of steps. Redirecting this to the tagging@ list - let's keep it here. Martin, I don't really know what you mean. Perhaps I don't understand the type=area proposal properly. Can you give us a full example (i.e. the tags) of how you would map those curved steps? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Orphanage
On Wed, Jun 2, 2010 at 3:38 PM, John Smith deltafoxtrot...@gmail.com wrote: On 2 June 2010 14:37, Roy Wallace waldo000...@gmail.com wrote: Is this a characteristic of the feature (that should be tagged), or of the residents (that shouldn't be tagged)? I'd say both... In that case, I'd tag specifically what you mean. For the example given, Some of the residents stay there all the time, some come for visits, use: residents:permanent=yes + residents:temporary=yes. Simple. No need to worry about whether or not this should be called an orphanage or not. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] John's import of towers/transponders
Re: John's recent important of man_made=tower nodes and type=transponder relations from ACMA: shouldn't the node's role be tower, not transponder? i.e. the *relation* represents the transponder (hence type=transponder), but the *node* represents the *tower*, so should have role=tower. (e.g.: http://www.openstreetmap.org/browse/node/740881798) I'm pretty sure my logic, above, is right - the role of the tower node should be tower, not transponder. Anyone disagree? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New Keys?
On Tue, Jun 1, 2010 at 5:58 PM, Liz ed...@billiau.net wrote: Option 1 Industrial=factory/workshop I don't like this key. To me, that reads this feature is an *industrial*, of type *factory*, or the *industrial* of this feature is a *factory*. Maybe try to fill in the blank: a factory is a kind of ? I would use that as the key. factory=furniture/cars/aircraft_parts I think you actually mean product=furniture/cars/aircraft_parts? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Orphanage
On Wed, Jun 2, 2010 at 12:21 PM, Stephen Hope slh...@gmail.com wrote: amenity=assisted_living + assisted_living=orphanage, OR amenity=assisted_living + residents=children. Hmm - not all homes for children are for orphans. There is a home near me that is for children/youth with very heavy caring needs, that cannot be handled by their families. residents:caring_needs=heavy residents:can_be_handled_by_their_families=no Obviously this is tongue-in-cheek, but I hope you see my point. Some of the residents stay there all the time, some come for visits when their carers are unavailable (ill, away, or just need a break). Is this a characteristic of the feature (that should be tagged), or of the residents (that shouldn't be tagged)? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Base transceiver station
On Wed, Jun 2, 2010 at 11:59 AM, John Smith deltafoxtrot...@gmail.com wrote: I recently imported 2,152 locations, that have between them 7,633 transmitters. Most of the towers had multiple transmitters so these were added using a relation linked to the tower node, eg this location has 17 transmitters: http://www.openstreetmap.org/browse/node/740881798 I'm not sure if I should start a new thread for this, but John: shouldn't the node's role be tower, not transponder? i.e. the *relation* represents the transponder (hence type=transponder), but the *node* represents the *tower*, so should have role=tower. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - traffic jam warning
On Sat, May 29, 2010 at 3:40 PM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Would be nice if someone comes up with a way to make this tag more verifiable, but if there's no better way to get this information into the database, than unverifiable info is still better than no info at all. Agreed. One way to make it more verifiable is to avoid using a broad, complex description (e.g. if A or B and usually C...) for a single tag (jam=yes). Instead, as I suggested before, clarify what you mean in the tag itself, e.g. traffic_jam:expected:daily=yes, or traffic_jam:warning_sign=yes, or traffic_jam:average_delay=10min. As a mapper I would find those tags MUCH easier to read and easier to verify than jam=yes. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] religion
On Sun, May 30, 2010 at 8:42 AM, Liz ed...@billiau.net wrote: Neopaganism as an overall term could meet Roy's standards of verifiability. Religion and verifiability do not belong in the same thread :P ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - traffic jam warning
On Fri, May 28, 2010 at 8:07 PM, Martin Bober mar...@bdd-music.de wrote: Hi folks, I have filled in a proposal for a tag indicating a high risk of traffic jams and would like to hear your comments. Nicely put together proposal with examples - good work. BUT jam=yes is not verifiable. Anything entered in OSM should be able to be demonstrated as correct or incorrect. That an intersection has a high risk of traffic jams is not verifiable IMHO. For more info: http://wiki.openstreetmap.org/wiki/Verifiability ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed feature : World wide place=* standardisation only based on population
On Fri, May 28, 2010 at 9:16 PM, sly (sylvain letuffe) li...@letuffe.org wrote: The problem I see with actual place usage is that it is not standardazided world wide and serves merly for writing a label on a map. It makes it quite hard for newcomers to guess in wich case they should use wich place, and that proposal tries to help have a first easy step to record at least a population estimation. Please compare this situation to what happened recently with the meaning of highway=*. Do you think highway=* tags are used to tag for the renderer? In some ways, yes, they are. But more specifically, highway=* tags are a very general and sometimes vague description of the importance of the highway for the road grid. I think place=* is designed to serve a similar purpose - importance in the urban texture. On jeudi 27 mai 2010, Roy Wallace wrote: I like your motivation. But maybe it's not necessary. Using population=* achieves the same goal. Yes it does, and it does much more precisely, this is the utimate solution. Unfortunetly, having access to this information is much harder when you are driving your car thru, than a rough estimate that gives you the approximate size of a hamlet (I have to admit that the upper part of the scale is kind of useless as population data is much easier to get in those cases) If you CAN estimate the population, use population=*. If you CAN'T estimate the population, then - with your proposal - you can't decide the value of place=*, anyway. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - traffic jam warning
On Sat, May 29, 2010 at 8:42 AM, Martin Bober mar...@bdd-music.de wrote: jam=yes is not allways impossible to verify. I guess it's arguable. If this does go ahead, I'd at least suggest a more descriptive tag, like traffic_jam:expected:daily=yes, or traffic_jam:warning_sign=yes. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed feature : World wide place=* standardisation only based on population
On Fri, May 28, 2010 at 12:28 AM, sly (sylvain letuffe) li...@letuffe.org wrote: Here is another try for world wide standardisation of places in order to hopefully try to create a consistent database I like your motivation. But maybe it's not necessary. Using population=* achieves the same goal. Consider the highway=* tag, which has come to refer to the importance of the highway for the road grid. Compare this to Simone's suggestion that the place=* tag should refer to an idea about the urban texture of the country. Very similar ideas. If Simone's suggestion is the consensus, perhaps it is worth trying to clarify this further. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed feature : World wide place=* standardisation only based on population
On Fri, May 28, 2010 at 7:35 AM, Andrew wynnd...@lavabit.com wrote: I like your motivation. But maybe it's not necessary. Using population=* achieves the same goal. There are two serious flaws with using population=*. The first is that you have to put in populations for absolutely everywhere; the normal OSM practice of leaving unresearched attributes blank frustrates any application using explicit populations. The second is that the area to take the population of is often ill-defined and may vary depending on the context. My point is not that we should necessarily even use population=*. My point is that this proposal is redundant. There is no reason to use place=* to indicate the population. IF you want to indicate the population, use population=*. i.e. Tag what you mean. It is a similar argument to saying that highway=* should not be used to indicate the number of lanes: Use lanes=* for that, and use highway=* for some other purpose. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Orphanage
On Fri, May 28, 2010 at 3:14 PM, Steve Bennett stevag...@gmail.com wrote: How about: landuse=residential residential=childrens_home The benefit of two-tiered tags like this is renderers (and other tools) only need to support landuse=residential to get something that's approximately right. Right idea, but from my perspective landuse=* shouldn't be used to describe an individual feature (like an orphanage), but to describe the use of an area of land. If you want to do tiered tags like this you'd use something more like amenity=residential_home + residential_home=orphanage. I.e. an orphanage is a type of residential_home is a type of amenity. NOT a childrens_home is a type of residential is a type of landuse. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: Parking for businesses..
On Fri, May 21, 2010 at 6:34 AM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: One problem I have with the concept of access=destination, even beyond the fact that it says right of access, is that parking lots quite often aren't connected to the places they serve. Something like access=customer is therefore *more general*. The parking lot might be across the street from the destination. Is access=destination accurate then? I think in these cases you'll have to describe in some way where is the connection, this is neither solved by customer or destination alone. True, but this is a secondary issue, to be solved by a relation. At least parking_use=* gets you halfway to a full solution. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
On Thu, May 20, 2010 at 7:36 AM, Tyler Gunn ty...@egunn.com wrote: Access=private works fine, then (along with access=public andaccess=permissive). Preferably with an additional tag (or relation) withsome indication of who is allowed to park there. Maybe access=customer isn't needed after all. How about something like: access=private permitted=patron/permit_holder/staff There's probably other valid permitted types, but this organization would handle the following types of situations quite well: - Public parking lot (ie you come here and pay to park, regardless of where you're going): access=permissive - Store parking lot for customer: access=private, permitted=patron - Store parking lot for staff only: access=private, permitted=staff - Parking lot for monthly parkers: access=private, permitted=permit_holder A relation to define what businesses are served by the lot could be something like: type=parking_use Where you'd have member roles: lot: a parking lot(s) for_use_by: the business(es) that the parking is intended for. I think in most circumstances it is probably pretty clear which business a parking lot is intended for though. Rather than permitted=*, why not use parking_use=*? That would then be consistent with your proposed relation. Though permitted is more general and might be able to be generalised to other features... I suggested a similar solution a couple of days ago: Alternatively, for parking, use the key use (as a noun) instead of [or in addition to] access, as in use=public/customer/private. There are then a few options for defining the values of parking_use, e.g. my public/customer/private or your patron/staff/permit_holder, or some combination thereof... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
On Tue, May 18, 2010 at 3:10 PM, Roy Wallace waldo000...@gmail.com wrote: I propose to add the following to the Parking wiki page, in the table of the Tags section, as follows: (http://wiki.openstreetmap.org/wiki/Parking) Column Key: access Column Value: public/customer/private Column Element: [node or area] Column Comment: Specify the intended users of the parking lot. access=public if intended for the general public, access=customer if intended only for those who are visiting nearby shops/amenities, or access=private if access is more restrictive than access=customer (e.g. for staff only, or requiring specific permission). Sorry, let me try that definition one more time: Specify the intended users of the parking lot. access=public if parking is available for general public use; access=customer if parking is only for those who are visiting nearby shops/amenities; access=private if access is otherwise restricted (e.g. for staff only, or requiring specific permission, etc.). Only use access=customer or access=private if this restriction is signed or otherwise enforced. The final sentence is to make the tag verifiable. Thoughts? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
On Tue, May 18, 2010 at 5:23 PM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Use access=permissive instead of access=customer and you get what's in use for years. http://wiki.openstreetmap.org/wiki/Access says access=permissive means The owner gives general permission for access. This doesn't seem consistent with parking restricted to customers. Do you think this is a problem? I think, if access=* is to mean something different when applied to a parking lot, I would like the wiki to be updated to be more explicit about it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
On Wed, May 19, 2010 at 6:57 AM, Seventy 7 seven...@operamail.com wrote: Use access=permissive instead of access=customer and you get what's in use for years. http://wiki.openstreetmap.org/wiki/Access says access=permissive means The owner gives general permission for access. This doesn't seem consistent with parking restricted to customers. Do you think this is a problem? I think, if access=* is to mean something different when applied to a parking lot, I would like the wiki to be updated to be more explicit about it. I think access=permissive is the right tag, but the wording in the wiki could be improved and a convention for parking agreed. eg The owner gives general permission for access but where there is no public right of way. For example, use of a car park by customers only or permission to walk across a field Be careful. I think some public carparks, e.g. multi-storey parking, open 24 hours a day, charging a fee, run by a private business, are access=permissive. For car parks: Use access=yes for public parking, access=permissive for customer parking and access=private for staff parking, or whatever. I do agree that a convention for parking should be specified. But I DON'T think we should use access=permissive simultaneously with two very different meanings: 1) (wiki definition) privately owned land, for example by a business, with general access allowed to anyone 2) (the proposed parking-specific definition) access allowed to customers ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fixed position GPS receivers
On Wed, May 19, 2010 at 11:56 AM, John Smith deltafoxtrot...@gmail.com wrote: On 19 May 2010 11:48, Roy Wallace waldo000...@gmail.com wrote: From wikipedia: Surveying or land surveying is the technique and science of accurately determining the terrestrial or three-dimensional position of points and the distances and angles between them. These points are usually on the surface of the Earth, and they are often used to establish land maps and boundaries for ownership or governmental purposes. Exactly, these locations are used to monitor the movement of a tectonic plate, atmospheric conditions and potentially drift of GPS satellite locations, none of which has anything to do with used to establish land maps and boundaries That was quite a selective quote of my quote. The first sentence boils down to surveying = determining the position of points. And monitoring (which is indeed just determining on an ongoing basis) the position of tectonic plates are GPS satellites matches this definition. We'll have to agree to disagree then, Ok. tagging them as just another survey marker is a reduction of information to lowest common denominator. There's no need to lose information - just use other additional tags. How about man_made=survey_point + survey_point=fancy_tectonic_whatever_thing? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
On Tue, May 18, 2010 at 1:52 PM, Tyler Gunn ty...@egunn.com wrote: From http://wiki.openstreetmap.org/wiki/Parking: The distinction between public parking lots, customer parking lots (such as at cinemas etc.), and private parking lots (such as for staff in a business park) is handled with access=* tags. To me, reading that directly that would seem to suggest using one of three values: access=public, or access=customer, or access=private. I'd agree with the 3 values you proposed though; really access=customer is the only new one. Makes sense to me too because it allows for a true distinction between general public parking (like multi-story parkades that are in the business of parking cars regardless of where the people are going), and parking lots intended to service the customers of a store, business, etc. I propose to add the following to the Parking wiki page, in the table of the Tags section, as follows: (http://wiki.openstreetmap.org/wiki/Parking) Column Key: access Column Value: public/customer/private Column Element: [node or area] Column Comment: Specify the intended users of the parking lot. access=public if intended for the general public, access=customer if intended only for those who are visiting nearby shops/amenities, or access=private if access is more restrictive than access=customer (e.g. for staff only, or requiring specific permission). Thoughts? The main problem is that if we propose those values of access=* specifically for amenity=parking's, this is not consistent with http://wiki.openstreetmap.org/wiki/Access. I don't think that would be a big issue, though - just add something on http://wiki.openstreetmap.org/wiki/Access such as The tag access=* has a different meaning when applied to an amenity=parking feature. Alternatively, for parking, use the key use (as a noun) instead of access, as in use=public/customer/private. Again...thoughts? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Green areas that are not parks (revisited)
On Fri, May 14, 2010 at 1:20 AM, John Smith deltafoxtrot...@gmail.com wrote: leisure=garden garden=residential Much better. This clearly means you are tagging a particular *type* of garden. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Green areas that are not parks (revisited)
2010/5/10 Petr Morávek [Xificurk] xific...@gmail.com Until there is a better solution I'll use the proposed scheme of landuse='residential' + residential='garden'. FWIW, I don't like that. Look at residential=garden...someone lives in the garden? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Green areas that are not parks (revisited)
On Fri, May 7, 2010 at 4:01 AM, Jonas Minnberg sas...@gmail.com wrote: That is what I like about it - when all I can find out about an area is that is green and lies in between buildings, yard is an appropriately vague word. You say you only know two things: 1) it is green -- color=green (IMHO, this is silly - don't bother mapping this) 2) lies in between buildings -- just map the buildings with building=yes areas On the other hand, if you actually know that it's a private garden, then that's a different story - see the other posts about how to tag this. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging for discount stores in US
On Fri, May 7, 2010 at 7:13 AM, John Smith deltafoxtrot...@gmail.com wrote: well, yes, but within the US at least, i think there's broad agreement that one tier of department store (walmart, kmart, target) is discount with respect to another (macys, pennys, nordstrom, etc.) The same thing is true of Australia... I disagree that there's broad agreement here on what stores are discount stores. I've never heard anyone in Australia refer to Kmart or Target as a discount store. I have heard this word used for, say, Crazy Clarks or Dollars and Sense. But I would have trouble objectively defining what it is, exactly, that makes Crazy Clarks a discount store. Seeing discount=yes tagged on a Target store would confuse me. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Thu, May 6, 2010 at 9:04 AM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Am 05.05.2010 22:36, schrieb Roy Wallace: There's only room for grey (w.r.t. the OSM definitions) if we want there to be. Following the OSM discussions for years now I would say: That's an illusion. Ok. Though I don't understand, I'll take your word for it and shut up :) I think I do understand your point, though, that you think it better to keep using these tags in a fuzzy, subjective, variable way throughout the world. Trying to redefine a vague definition existing for years with something more exact a lot later on is just asking for trouble. Ok, I'll give up. But I will just point out that, while you insist it is just asking for trouble, imagine a wiki page that says something like: If you're not sure whether the place should be tagged as an amenity=restaurant, cafe or fast_food, this flowchart is provided as a guide. However, keep in mind that these tags have been used vaguely and subjectively for years, and may continue to be used as such into the future. That seems an improvement to me, but it appears I am alone. Bye. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Thu, May 6, 2010 at 9:41 AM, John Smith deltafoxtrot...@gmail.com wrote: On 6 May 2010 06:12, Roy Wallace waldo000...@gmail.com wrote: I would think a semi-colon delimited value would be better in this case - certainly better than multiple POIs, and no less supported than multiple relations (right?) If an app supports relations, it wouldn't matter if there is 1 or 10, however most software I've tried doesn't bother to expand multiple values separated by semicolons... You're right, actually. But it seems like a pretty nasty hack to use relations for this purpose, that is, simultaneously defining more than 1 value for a key. From the wiki: relations are basically groups of objects in which each object may take on a specific role. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
(note: removed talk-us) On Tue, May 4, 2010 at 2:39 PM, John Smith deltafoxtrot...@gmail.com wrote: ... It's a big world out there and there is bound to be grey areas that local knowledge will tags things one way or the other... There is bound to be grey areas only if we continue to use these tags as currently defined in the wiki. The problem is that we must choose amenity=A OR B OR C, where A, B, and C are not mutually exclusive. This is the cause of the problem. We either need to: 1) allow for the specification of more than one type simultaneously, e.g. amenity=A;B, amenity=B;C, etc., or 2) change/specify in more detail the definitions of A, B and C so that they *are* mutually exclusive, or 3) be forced to tag things incorrectly Which option shall it be? I vote 2, which includes the option of just using amenity=D (where D=A OR B OR C) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Wed, May 5, 2010 at 10:19 AM, John Smith deltafoxtrot...@gmail.com wrote: On 5 May 2010 09:22, Steve Bennett stevag...@gmail.com wrote: (Just to make life even hearder: is McCafe a cafe or fast food?) Maybe it's all three at the same time... Does it have a sit down and eat area restaurant Is the food delievered in less than 5 minutes (usually)... fast_food Is there a distinctive cafe section which primarily does coffee and muffins cafe Is there anything wrong with using: amenity=cafe;fast_food;restaurant? If not, that approach, plus those 3 definitions from John look pretty good to me (although maybe replace muffins with cooked snacks, or something). Whack all of that on the wiki, plus define amenity=food for a place serving food that doesn't meet any of the other definitions, and we should be able to avoid having this conversation again. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Wed, May 5, 2010 at 11:10 AM, Greg Troxel g...@ir.bbn.com wrote: The entire reason such tagging is useful (vs. amenity=food) is that people can ask find me a nearby cafe. When I ask that, I want a coffee shop that serves sandwiches, or a sandwich shop that serves coffee, or something like that -- that I'm likely to be glad I went to. I definitely don't want McDonald's If I asked find me a nearby cafe, a McCafe would be fine with me! One of the key distinctions in practice is that mega-corpooration heavily-advertised pseudofood is fast food, and independent coffee shops are cafe. At least that's how everyone I know sees it. Unfortunately, you don't know everyone. The Coffee Club, for example, is certainly not independent, but I'd call it a cafe. You can call this bias and subjectivity, but I call it communication based on a shared vocabulary. I call it bias and subjectivity. It's only a shared vocabulary if the vocabulary is shared. It's one thing to define amenity=cafe in a certain way that may be counter-intuitive to some (that's fine! put it on the wiki! I'll look up the definition!), but it's madness to not bother defining it at all. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Wed, May 5, 2010 at 2:32 PM, John Smith deltafoxtrot...@gmail.com wrote: It would be better to tag the primary function of a business, and add modifiers... So amenity=fast_food + cafe=yes would be roughly equivalent to amenity=cafe + fast_food=yes? Interesting proposal. It seems like a plausible workaround for indicating a plurality of amenity=* values without resorting to a semicolon-delimited list - though it remains a *workaround*, nonetheless. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
On Mon, May 3, 2010 at 8:41 PM, John Smith deltafoxtrot...@gmail.com wrote: Why does it need to be a unifying criteria? Provide the tags, people will come up with their own criteria based on their own cultural background, while they will be similar, there will be subtle differences. I think we can avoid having multiple meanings for identical tags in the OSM database. (though I realise you disagree, John). As for cafe vs. restaurant vs. fast_food, to look at the bigger picture...I'm seriously wondering whether those tags even have *verifiable* distinctions (of course, this depends on their definition). If the value is not verifiable, cafe/restaurant/fast_food tags should not be used, and instead they should be replaced with amenity=food (or equivalent). At least that can be verified. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Turning gate on footpaths
On Wed, Apr 14, 2010 at 2:40 AM, John Smith deltafoxtrot...@gmail.com wrote: You don't need motorcar=no for the barrier, you'd tag the way with it. Really? I thought: You'd tag the way if you want to indicate that you're legally not allowed to use a motorcar along the way (http://wiki.openstreetmap.org/wiki/Access) You'd tag the barrier if you want to indicate that cars are blocked by the barrier. So as Alex said, it might depend on the situation and definitely depends on what you want to indicate. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Beaches
On Sun, Apr 11, 2010 at 9:10 AM, John Smith deltafoxtrot...@gmail.com wrote: I don't see an overly compelling reason to change the existing tag, Me either. In my previous post I was actually trying to point out the problems with the landuse tag, rather than advocate it. I think natural=beach is fine to describe an area of sand that resembles a beach (regardless of whether humans have created it or use it), just as natural=water tends to be used to describe an area of water. however there are things like golf course bunkers that are sand but aren't a beach that probably shouldn't be tagged natural=beach like some people did in the past to make the bunkers render. Surely these should be tagged golf_course=bunker, or something. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Beaches
On Sun, Apr 11, 2010 at 11:18 PM, John Smith deltafoxtrot...@gmail.com wrote: On 11 April 2010 20:40, Roy Wallace waldo000...@gmail.com wrote: Surely these should be tagged golf_course=bunker, or something. I was hoping for something a little more generic Suggestions? As is, you can't use surface because that's only for roads/footpaths (although strangely it's also used for leisure=pitch's - seems the wiki needs updating). And landuse is perhaps problematic for the reasons I mentioned before (i.e. overlap with natural). Although, landuse=sand would be analogous to the current use of landuse=grass. you can also have beach volley ball areas that are no where near beaches leisure=pitch + sport=volleyball (or beach_volleyball, I would suggest) + surface=sand (see http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpitch) there is also sand in deserts, I'd suggest natural=desert (+ maybe surface=sand). Strangely abandoned old proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Deserts and sand dunes that aren't desert but aren't part of a beach either. Surely natural=sand_dune ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Beaches
On Mon, Apr 12, 2010 at 9:04 AM, John Smith deltafoxtrot...@gmail.com wrote: On 12 April 2010 07:50, Roy Wallace waldo000...@gmail.com wrote: Suggestions? As is, you can't use surface because that's only for roads/footpaths (although strangely it's also used for Why does the surface tag have to be limited to roads/footpaths? It doesn't have to be in future. It's just what the wiki says at the moment. landuse=sand might be suitable for a sand mine, but the term landuse to me indicates what it's being used for, not what covers the ground eg landuse=residential etc has no relation to the top soil Good point. I assume you disagree with the use of landuse=grass, then? (which is listed at http://wiki.openstreetmap.org/wiki/Landuse) leisure=pitch + sport=volleyball (or beach_volleyball, I would suggest) + surface=sand (see http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpitch) You are contradicting what you said earlier about surface... Well, the wiki page for surface=* contradicts the wiki page for leisure=pitch. I think the latter is better. Anyway, the approach seems to be to 1) mark what the feature is, then 2) mark what the surface is, and if necessary 3) mark what the area is used for. So for the bunker, golf_course_obstacle=bunker (or whatever) + surface=sand sounds fine to me. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Beaches
On Sun, Apr 11, 2010 at 3:36 AM, John Smith deltafoxtrot...@gmail.com wrote: I don't think it matters if it's a man made beach or not, natural=tree is used for planter boxes in the middle of the street, I'm pretty sure that isn't 100% natural :) Hmm. Yes, we also have natural=water whether it's natural or notBut this doesn't necessarily mean it's the best solution. surface=sand is also not the best solution, because surface=* is specifically for surface of roads/footpaths. The only alternative I see is landuse=beach, which I think would be ok, if there were a clear distinction between this and natural=beach. For a beach created by dumping a bunch of sand in the middle of a city, to me, that's pretty clearly landuse=beach. But in Australia sand, is frequently dumped on beaches bordering the sea, to top up the sand for the tourists. At what point would that change from natural=beach to landuse=beach? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Narrow width
On Tue, Feb 23, 2010 at 5:19 AM, Colin Smale colin.sm...@xs4all.nl wrote: Don't want to stir up a whole new hornet's nest, but would that be kerb-to-kerb (i.e. tarmac width) or wall-to-wall (limiting the overall vehicle width)? Good question. The wiki simply says width of a way. So it's impossible to say without a more detailed definition, or knowledge of what others have been using it for. I would *guess* that, for a highway=*, it should refer to the maximum legally usable width by a vehicle, or something like that. So that would mean kerb-to-kerb width, unless it's legal to ride on the sidewalk in that locale. You could, of course, propose new tags: width:tarmac=* and width:clearance=* (or something), if you want to get more specific. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] US Speed Limits, truck routes, bike routes, access
On Sat, Feb 27, 2010 at 8:32 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: Several issues with relation to speed limits: 1. How should one tag suggested speeds (usually around curves) ... ... Should I tag them as maxspeed=*? The wiki says maxspeed is for the maximum speed that is allowed (i.e. allowed, not suggested). I'd be in favour of proposing a new tag, like maybe maxspeed:suggested, or suggestedmaxspeed. maxspeed:children_present=25 mph source:maxspeed_children_present=survey;image ... I changed the : to _, not being sure if we want to deal with multiple levels of children. I would prefer source:maxspeed:children_present, i.e. keep it in the form: source:key name. I expect this would be easier to parse. In CA, the standard speed limit on freeways is 65mph normally, but 55mph for trucks and towing/towed vehicles. This results in 9 tags(!), providing more reason for some sort of scheme like maxspeed=freeway. Are these standard speed limits verifiable (i.e. marked on-the-ground?) If so, then 9 tags is fine - I don't see this as a reason to support the introduction of a *less explicit* scheme. ... I'd like to create a node where I first see a No Trespassing sign (http://en.wikipedia.org/wiki/File:No_trespassing_sign.jpg). Should I tag the node access=private [+source=* +source_ref=*]? I don't think so. What does the node represent - the sign? If so, tagging the node in this way seems to mean the public are not allowed to use *this sign*. :P Tagging a node with access=* does, however, make sense for a gate (node). If you want to mark the presence of the sign, how about traffic_sign=*? (http://wiki.openstreetmap.org/wiki/Key:traffic_sign) ... I can then tag the way with source:access=* +source_ref:access=*. I'd prefer the *section of private way* to be marked as such using access=private. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:geolocation?
On Tue, Feb 23, 2010 at 4:29 PM, Steve Bennett stevag...@gmail.com wrote: 1) Use source:X to refer to geolocation, where X is some string that is never going to be used as a key on its own, or Solution 1 looks perfectly good to me. Position, location, whatever. If a consensus ever emerges, it's trivial to normalise them. Yeah that seems to be the consensus here. Does anyone feel strongly about needing a vote for this, or should I go ahead and add source:location to Map Features and Key:source on the wiki? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Narrow width
On Tue, Feb 23, 2010 at 5:36 PM, Steve Bennett stevag...@gmail.com wrote: I come to a road with width=3 - that is indeed useful. I come to a road with narrow=yes - that is not as useful. I just don't understand how everyone can have the same argument, again and again, about every new tag or idea suggested. That's because it's a good argument. ... Now, the concept of narrow ... could be defined by the presence of warning signs, by reference to standard road widths in the area, or simply the mapper's intuition. If you propose a verifiable definition for narrow, I will support it. But warning signs OR reference to standard road width OR intuition is not verifiable. There you go, the same argument once again - it's not going to go away... :) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:geolocation?
On Wed, Feb 24, 2010 at 7:40 AM, John Smith deltafoxtrot...@gmail.com wrote: Pick which ever has the most widespread use and document it. Hmm now that I check again, [1] lists a few hundred uses of source:position, but only 2 uses of source:location. Better go with source:position, then. [1] http://tagwatch.stoecker.eu/Germany/En/tags.html ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:geolocation?
On Thu, Feb 18, 2010 at 3:39 PM, John Smith deltafoxtrot...@gmail.com wrote: Did you check tagwatch for the most common reference to source:*location* ? Some from Tagwatch Australia: 60 source:location 46 source:geometry 7 source:existance 3 source:area Some others from OSMdoc (in descending order of frequency): source:position source:outline source:location source:existance source:geometry ...etc. But I think this deserves further thought, anyway. I can see only two possible solutions: 1) Use source:X to refer to geolocation, where X is some string that is never going to be used as a key on its own, or 2) Redefine source=* to refer to the geolocation of the feature only (as opposed to all tags of the feature) I don't particularly like either solution... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:geolocation?
On Fri, Feb 19, 2010 at 3:12 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: I have no opposition, though, to the more precise: source:location=survey;usgs_imagery + source:name=survey;image;LACA source:location=* sounds good, as long as there is never going to be a location=* key introduced (which would then make the meaning of source:location=* ambiguous). If we're confident of this (are we?), I think source:location=* should be recommended on http://wiki.openstreetmap.org/wiki/Key:source, to discourage people from simultaneously using other synonyms like source:position, source:outline, source:geometry, etc. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:geolocation?
On Fri, Feb 19, 2010 at 9:22 AM, Cartinus carti...@xs4all.nl wrote: 3) Nuke alle source tags on database objects, because they are not data but metadata. Then put decent descriptive comments/tags on your changesets. This doesn't solve the problem (please start a new thread if you want to talk about changeset vs. feature tags). How would you explictly indicate the source of the geolocation of features, as opposed to the source of other information? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Narrow width
On Fri, Feb 19, 2010 at 10:13 AM, Dave F. dave...@madasafish.com wrote: If users are so incompetent at judging distances then maybe they should never hve picked up a GPS in the first place. Or they should use est_width=1.5m + note=road looks narrow - please confirm width ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] source:geolocation?
Gday, I'm a big fan of source:*=*. This allows for a road to be tagged with e.g. source:name=survey + source:surface=nearmap But there doesn't seem to be any way to specify the source of a feature's *location*. Consider this scenario: There is a petrol station POI that someone has tagged with: amenity=fuel shop=kiosk And let's say I know from memory that it's called Foo Fuel, so I add the tags: name=Foo Fuel source:name=knowledge Now, let's also say I trace the building outline from nearmap imagery, copy the tags onto the building outline and delete the original node. How should I indicate that I traced the building outline from nearmap? I could add source=nearmap, but that might also imply that source:shop=nearmap, which isn't true. Thus...is there a need for a new tag like source:geolocation? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] adjacent buildings
Should buildings adjacent to each other be mapped: 1) individually, with shared boundaries 2) individually, with an arbitrarily small gap between boundaries 3) as one contiguous area? An example of a row of adjacent buildings: http://www.openstreetmap.org/?lat=-27.664894lon=153.031072zoom=18layers=B000FTF. The roofs of the buildings are distinguishable from each other using aerial imagery, but the row of buildings may well appear as a single building from the ground. I tend to think 1) or 3) is the correct solution. I hesitate to use 3) due to [1], which says: For areas adjacent to ways, the consensus is to generally leave a small gap between the area and the way instead of sharing the boundary. What about *areas adjacent to areas*? [1] http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Tagging_Areas ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] adjacent buildings
On Mon, Feb 8, 2010 at 9:44 AM, Eugene Alvin Villar sea...@gmail.com wrote: Are these buildings conceptually separate (e.g., different building management or construction dates)? If yes, map as separate areas sharing boundaries. I don't know - source is aerial imagery. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal image=http:/... .jpg
On Sun, Feb 7, 2010 at 3:44 AM, Ulf Lamping ulf.lamp...@googlemail.com wrote: ... Yes, there can only be one photo to represent the OSM object. Why? You could just as easily use image=img1;img2;..., though this clearly doesn't scale well (which may suggest that this isn't a good approach...) I think what Tobias is getting at is that there's perhaps no correct value for the image=* tag. Some will see this as a bad thing, and see this as meaning that its value is not objective. If the value of image=* for a feature is defined as one or more images that show the feature, then I think that this is at least verifiable, in that the tag can be said to be true or false. So I don't see a huge problem - but it's not something that I'd be interested in using. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:06 PM, John Smith deltafoxtrot...@gmail.com wrote: Imagine a mechanism in your favourite editor when you can drag the width of the node outwards to match the width of the road, this then gets stored against the node information for the way. Ah ok. Hmm, I'd prefer that the OSM way is the centerline of the feature. This would mean: 1) the OSM way is consistently meaningful in itself, and matches current usage 2) you only have one width value per node, which might simplify editing. But it seems like you're suggesting that the OSM way instead should represent: a) if a oneway feature: the centerline b) if a twoway feature: the divider between traffic travelling in each direction Could work I guess... the thinner lines are lanes. Huh? Do they exist in the database? If so, as what? That's part of my goal with all this, to make them exist. way id='-1' visible='true' nd ref='-1' width='50' lanes:left='2' lanes:right='3' / nd ref='-2' width='40' lanes:left='2' lanes:right='2' / /way Or something to that effect. Ah now I see what you mean. Can you add all of the necessary tags to the example in your diagram? In particular: 1) please indicate the geometric interpretation of width='50' and width='40' 2) write out the lane tags next to each node. I think you'll quickly see that it's difficult to decide how many lanes:right the middle node has, i.e. 2 or 3? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Wed, Feb 3, 2010 at 5:25 PM, John Smith deltafoxtrot...@gmail.com wrote: This is tagging the way, but at the node references. I let this go a couple of days to see if anyone would find any problems with doing this. It is one option for tagging width, but users would then still need to make some assumption about the direction in which width is measured (probably the bisection of the angle between previous/following nodes) and interpolate between nodes (probably linearly). It's also (at first glance) a very big change to the OSM data model. There may be other problems, but that's the main one I can think of. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:31 AM, John Smith deltafoxtrot...@gmail.com wrote: On 4 February 2010 07:24, Roy Wallace waldo000...@gmail.com wrote: I guess...but this might be tricky for editors to deal with when way direction is reversed. Not really, think of the bits between nodes as segments, you apply the information to a segment, except width which is applied at the specific point, the rest is just vector type informaiton. Upon reversal of the way, editors would have to automatically convert [1] to [2]. http://www.myimgs.net/images/lmwa.gif http://www.myimgs.net/images/mjrp.gif Still feasible, but it is worth noting. Also, a maxspeed conceptually applies to a way, not a node. This is therefore only worth doing if you really really want to avoid splitting ways. The problem at the present is ways get split for a lot of reasons, this may reduce the amount of splitting. I know. But if you are happy with splitting (as I am), then the current solution is fine. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:32 AM, John Smith deltafoxtrot...@gmail.com wrote: On 4 February 2010 07:22, Roy Wallace waldo000...@gmail.com wrote: It is one option for tagging width, but users would then still need to make some assumption about the direction in which width is measured (probably the bisection of the angle between previous/following nodes) and interpolate between nodes (probably linearly). If you assume the node is the mid point of the way, width at that point is simply the width, and the width at the surrounding points is that width and the rest is just vector math. I have no idea what you're talking about. This is my interpretation of your idea, as it stands: http://www.myimgs.net/images/plxo.gif If I've got the wrong idea, please draw a diagram of what you mean :) It's also (at first glance) a very big change to the OSM data model. There may be other problems, but that's the main one I can think of. Bigger than relations? No idea. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Proposed feature: Gated Communities
On Thu, Feb 4, 2010 at 10:50 AM, Steve Bennett stevag...@gmail.com wrote: We will have to consider what to do about the fact that you'll end up with nested landuse=residential Simple: the tags on the inner polygon override those on the outer polygon. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Race track
On Mon, Feb 1, 2010 at 8:25 AM, Dave F. dave...@madasafish.com wrote: Post a link when you've completed it; I'd like to see the results. I've created a MP with highway=racetrack. I haven't marked centerlines yet: http://www.openstreetmap.org/browse/relation/399272 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Race track
On Mon, Feb 1, 2010 at 9:43 PM, Dave F. dave...@madasafish.com wrote: As the track will be the entity most people would expect to see on the map, tag that as highway=raceway. Tag the way as some like highway= 'racing_line'. ... Creating a new tag is not a problem, especially if it's solving a problem that hasn't yet been solved. Thanks, that's not bad...But if you wanted to eventually have the option to do a similar thing for other highway's, you'd have to create a new tag for every one of them (e.g. highway=track + highway=tire_grooves!). I would have thought there might be a more elegant solution. It's not been commented on either. I'm not sure if this proposal is widely known about. It's linked from http://wiki.openstreetmap.org/wiki/Relations, which I always check before suggesting something new. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Islands in Parking Lots
On Sun, Jan 31, 2010 at 3:37 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: it is not about needing the inner polygons, they describe the situation better and enter more detail - regardless of case a) or b). Maybe I should clarify - I'd prefer to see a natural=grass area (or whatever) *within* the amenity=parking area (i.e. with the amenity=parking area subsuming the natural=grass area). The natural=grass area can be part of the amenity=parking area - i.e. not necessarily mutually exclusive. Of course, this is just a matter of preference, due to a subtle difference in the definition of amenity=parking. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Islands in Parking Lots
On Mon, Feb 1, 2010 at 1:21 AM, Anthony o...@inbox.org wrote: What tag should we use for places that people can park? If you literally mean place that people can park, this is verging on unverifiable (e.g. well *I* think I can park there...) On the other hand, a parking bay (i.e. marked with lines) is fine if you want to tag the little rectangles of concrete - I'm not sure on a tag though. Are there precedents in marking, basically, very small patches of concrete? Maybe a landuse tag? It's not an amenity, and it's not really a highway (though it is similar in some aspects to a highway=pedestrian)... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Race track
On Mon, Feb 1, 2010 at 3:36 AM, Dave F. dave...@madasafish.com wrote: ... the River/Riverbank could be the solution: Use multi-polygons for the boundaries of the track/pit lanes etc. Then add separate ways for to indicate each track configuration. Thanks - exactly what I was looking for. I'm guessing the multi-polygon and the ways should both be tagged in the same way (i.e. highway=raceway, name=*, surface=*, etc.)? Is there really no tag needed to indicate to renderers that the width of the way is indicated by the multi-polygon rather than the way (centerline)? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Race track
On Mon, Feb 1, 2010 at 8:25 AM, Dave F. dave...@madasafish.com wrote: Is there really no tag needed to indicate to renderers that the width of the way is indicated by the multi-polygon rather than the way (centerline)? No, not for the renderer, they only render what is tagged, not what is not tagged. I'm not sure I understand. What I mean is, if the database contains a way with highway=raceway, *as well as* a multi-polygon (MP) with highway=raceway, how would a renderer know not to try to render *two different raceways*? Is it their responsibility to check whether the way is *within* the MP area, and then infer that it describes the *same* raceway...? I think it would be prudent to explicitly state this relationship between the way (giving centerline) and the MP (giving area)...with a relation. I think we could use [1], with type=area, role=center (for the centerline way) and role=area (for the MP). Post a link when you've completed it; I'd like to see the results. Will do. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 11:38 AM, John Smith deltafoxtrot...@gmail.com wrote: Going with Richards idea, what about making the editor do the grunt work, place a node at a point, and then have the editor calculate the width by stretching the road way side ways, then apply the width values against nodes, which would make areas redundent. Interesting, but what you're really doing (if i understand you correctly) is: 1) storing a way, plus 2) storing an approximate area (in the form of width tags applied to nodes on the way, and then using some form of interpolation between nodes). The alternative is: 1) storing a way, plus 2) storing an area ...and (optionally, but preferably) relating the two with e.g. type=area; role=center; role=area [1]. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 12:07 PM, John Smith deltafoxtrot...@gmail.com wrote: On 1 February 2010 11:59, Roy Wallace waldo000...@gmail.com wrote: Interesting, but what you're really doing (if i understand you correctly) is: You missed the point on lanes then, which is mostly what I'm interested in, being able to plot lanes and then describing them. I have no idea what you're talking about. Maybe it is best if you put together a proposal page so we can see all aspects of your idea(s) in one place... 1) storing a way, plus 2) storing an area How do you use an area to describe lanes and so forth? A lane could be described, geometrically, by an area (to indicate the space it takes up on the Earth's surface) and a way (to indicate the centerline and direction of travel). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 1:28 PM, John Smith deltafoxtrot...@gmail.com wrote: Why would it be any more difficult than using areas, if the editors display the data correctly then you can edit it correctly too. Think about it: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Nodes are the perfect point to do it, they are the 2D location, ways give you direction, nodes give you width. Erm no. You need to know along which direction the width is measured. You could *assume* that this is in the direction that bisects the angle between the previous and following nodes, but 1) this is an approximation and 2) this doesn't work if the node is connected to more than 2 other nodes. Thus... nodes are hardly the perfect point to indicate width. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Race track
On Mon, Feb 1, 2010 at 12:35 PM, Dave F. dave...@madasafish.com wrote: I'm not sure I understand. What I mean is, if the database contains a way with highway=raceway, *as well as* a multi-polygon (MP) with highway=raceway, how would a renderer know not to try to render *two different raceways*? Is it their responsibility to check whether the way is *within* the MP area, and then infer that it describes the *same* raceway...? Well I'd refer you back to the river/riverbank example give a different value for the mp; Kerb maybe or track_edge? Ah I see... hmmm it works, but it seems a bit strange. I feel like I'm marking a highway=raceway, not a highway=racewaybank... I'd hate to have to invent a new tag for every feature that I want to mark as an area (and as a way)... I think it would be prudent to explicitly state this relationship between the way (giving centerline) and the MP (giving area)...with a relation. I think we could use [1], with type=area, role=center (for the centerline way) and role=area (for the MP). This is new to me. What advantage would this bring? Out of curiosity was this discussed in any of the forums (Not that it had to to gain approval, of course)? Any working examples? New to me, too - I found it via search. Note that it's still only in /Proposed/. The advantages would be 1) No need to invent a new tag for each tag with an area-equivalent (e.g. river vs. riverbank) 2) Gives users the option to use the way representation (for e.g. routing) or the area representation (for e.g. rendering), while also knowing that the two representations refer to the same entity. Tags applying to the entity (e.g. the name of the race track) could be applied to the relation only rather than (redundantly) to both representations. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 3:26 PM, John Smith deltafoxtrot...@gmail.com wrote: On 1 February 2010 14:21, Roy Wallace waldo000...@gmail.com wrote: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Just like ways there is a lot of meta information to describe lanes, can you change lanes, do lanes have different speed limits, sure areas could be used for this, but the down side is you still need a way to describe the legal direction of travel, so the problem still exists an area alone doesn't describe everything. Indeed. Hence why I have said multiple times that I think a way PLUS an area is a better solution than trying to mangle the idea of an area into tags on nodes. Erm no. You need to know along which direction the width is measured. A node is a point, the direction of width would be 90 degrees to the direction of travel. See this drawing and tell me what the width tag means: http://www.myimgs.net/images/puan.gif So the question still remains, how to describe a road way more accurately with a single object. Why does it have to be a single object? A road has a centerline, and it has a footprint. Why not map both...? Here's a brainstorming picture, plenty of kinks to be worked out if anyone's up for a challenge: http://www.myimgs.net/images/psgb.gif E.g. if we're mapping ways as areas, how should the intersection area be tagged? Anyway, I'll now refrain from distracting you from writing up your proposal :) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 3:53 PM, Anthony o...@inbox.org wrote: OSM doesn't have areas, it has nodes, ways, and relations. Area means a closed way, with tags referring to the entity bounded by the way. Simple enough I thought. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Islands in Parking Lots
On Sat, Jan 30, 2010 at 9:27 AM, Richard Welty rwe...@averillpark.net wrote: a tree may be in a parking area, but how exactly do you propose to park on it? The more important question is what does amenity=parking apply to? a) a parking area, or b) a place you can park. I prefer a), because otherwise many, many flat surfaces near roads would be amenity=parking. In which case you don't need the inner polygons because a tree can be *in* an amenity=parking. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Islands in Parking Lots
On Sat, Jan 30, 2010 at 7:43 AM, Richard Welty rwe...@averillpark.net wrote: i should think if you use a multipolygon, they will obviously be dropouts from the parking area. I'm not sure... isn't a tree planted in the middle of a parking area part of the parking area? Or is there a really really specific definition of a parking area on the wiki that I missed? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
On Wed, Jan 27, 2010 at 10:33 PM, Steve Bennett stevag...@gmail.com wrote: Out of curiosity, what's your intention in tagging these things? I get tags like amenity=cafe or landuse=commercial, name=John's Software Consulting, but what kind of applications might make use of knowing that something is a software development house, but not knowing what it's called? Assigning a name=* to a landuse=* area is IMHO a bit strange anyway, because the landuse is not the thing that has a name - in which case, some of these might be better described by office=* + name=* (in addition to the landuse area that might cover a larger area than the office, or several offices with different names). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
On Wed, Jan 27, 2010 at 10:37 PM, Matthias Julius li...@julius-net.net wrote: Would you tag a business facility that is not really an office like a machine shop or other production facility as office=* as well? I would think not. There may be cases that are in the grey area, and if you can think of any examples (I can't right now) it's worth bringing up here. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
On Wed, Jan 27, 2010 at 10:40 PM, Simone Saviolo simone.savi...@gmail.com wrote: Why not use business=* instead? Because that overlaps with a BUNCH of stuff that already has tags (e.g. shop=*, a lot of amenity=*'s, etc.) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
On Wed, Jan 27, 2010 at 10:45 PM, Pieren pier...@gmail.com wrote: On Wed, Jan 27, 2010 at 1:33 PM, Steve Bennett stevag...@gmail.com wrote: Anyway, I like Liz's suggestion of tag first, then document and refine the scheme later. That's usually the method of the US police : shoot first and ask questions later. More like take into custody first and ask questions later. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
On Wed, Jan 27, 2010 at 8:51 AM, Woll Newall w...@2-islands.com wrote: The appropriate land-use tag is commercial (defined as Predominantly offices, business parks, etc.), so maybe such things should be tagged commercial=software_development, commercial=call_centre etc plus company name in the name tag? Not bad, but commercial is an adjective, not a noun. Perhaps office=commercial + commercial=* would be better? I dunno, surely there's been better thought out proposals on this before? I couldn't find any either... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dutch cafes (was: What's a power=station?)
On Thu, Jan 21, 2010 at 9:17 AM, Erik Johansson erjo...@gmail.com wrote: ... To meet both problems you can only do this: alcohol=yes coffee=no pastries=yes egg chips=yes I like this approach. It makes much more sense than either of the other suggestions, i.e.: 1) inventing complex explicit definitions of what a cafe is, internationally or 2) assuming complex (implicit) definitions of what a cafe is, and having this differ from place to place ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dutch cafes
On Thu, Jan 21, 2010 at 10:28 AM, Matthias Julius li...@julius-net.net wrote: On Thu, Jan 21, 2010 at 9:17 AM, Erik Johansson erjo...@gmail.com wrote: ... To meet both problems you can only do this: alcohol=yes coffee=no pastries=yes egg chips=yes I like this approach. I don't. I don't want to revisit each place each week to see whether the menu has changed. If a cafe is an amenity=cafe only if A, B and C, you would have to revisit each week, anyway, to check that it's still A, B and C. My point is that I like the approach of tagging A, B and C, instead. It would be foolish to assume that a café in Hongkong looks exactly the same as in Vienna. Yes...hence why I like the approach of tagging what you mean... Also, if you only tag the menu instead of categorizing the place you only put the burden on the consumer of the data. I disagree. If a cafe is a concept that's easily defined and internationally consistent, that's great, and telling the consumer there's a cafe is great. But if it isn't, then telling the consumer there's a cafe puts MORE burden on them to work out what that means, than specifically telling them there's a place you can get coffee and snacks, and Otherwise you get 10 icons on the map for each café (coffee, pastries, eggchips, ...). You don't have to render everything. Or, you have to ask your router to guide you to a place where they have beefsteak, beer and rum if you feel like that. That'd be great! I should mention that I'm not suggesting we completely scrap the amenity=* tag - but if we're finding it hard to agree on a definition of amenity=cafe, that would suggest to me it's not a good tag! Can we agree on a definition for amenity=food_or_drink_outlet, used in combination with the specifics? Much more likely, I think. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dutch cafes
On Thu, Jan 21, 2010 at 11:46 AM, John F. Eldredge j...@jfeldredge.com wrote: ... It seems more reasonable to tag the general cuisine, whether food is available, whether alcohol is available, whether reservations are required (usually only at fancier establishments), and whether the establishment allows children I think this is good... the point is to avoid using tags that have a fuzzy or variable meaning. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What's a power=station?
On Mon, Jan 18, 2010 at 6:19 PM, Liz ed...@billiau.net wrote: Redoing the tagging, and leaving the disputed tag out of the new scheme is a way to go forward. Redoing the tagging is a little vague. Introduce new tags to resolve ambiguities - use them in parallel with those specified on the wiki (as specified on the wiki), and when old tags become redundant, deprecate them. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Easy question: _link tags for U turn/cut throughs?
On Fri, Jan 8, 2010 at 1:59 PM, Steve Bennett stevag...@gmail.com wrote: When a divided motorway/trunk/primary/... has a spot for turning or u-turning, should that be marked as primary or primary_link? The wiki isn't clear. Well, what is it better described by: 1) link roads (sliproads / ramps) -- primary_link 2) A major highway linking large towns -- primary Given that, I'd say it's either primary_link, or something else. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Wed, Jan 6, 2010 at 4:06 PM, Steve Bennett stevag...@gmail.com wrote: On Wed, Jan 6, 2010 at 2:52 PM, Anthony o...@inbox.org wrote: therefore, highway=footway, bicycle=designated means highway=cycleway, foot=designated, which means highway=path, foot=designated, bicycle=designated. Yeah, it's a bit ugly. Should we be deprecating one or the other, or doing mass updates or something? I think so, but I don't think it's worth pursuing right now, as many are still attached to the redundant cycleway/footway tags. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Wed, Jan 6, 2010 at 4:15 PM, Steve Bennett stevag...@gmail.com wrote: The biggest problem I can see at the moment is I really don't want to tag anything bicycle=designated unless I'm certain it really *is* designated that way (which I can't do from aerial photography), but I *do* want to tag it highway=cycleway without such certainty. Or maybe I just tag it fixme=verify designation. I came across this problem too. Eventually I decided to just use highway=path, as that is all that can be confidently concluded from aerial photography. (leave the details for a later ground survey...) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Tue, Jan 5, 2010 at 3:31 PM, Steve Bennett stevag...@gmail.com wrote: Isn't that what a map is? Some kind of look-up service for the real world? There is a layer of interpretation in the middle, that's the crucial difference. I don't know what you mean. That tags have definitions? Some people on these lists think that we should just store random facts at a very fine-grained level, and that some future renderers and routers will magically be able to make sense of the mess. Close - rather, I think that we should just store VERIFIABLE facts at a very fine-grained level, and that some future renderers and routers will CONSISTENTLY be able to make sense of the DATA. I believe that the people best equipped to make sense of the facts are those entering them into the database, reducing the burden on present and future software developers. Again, I don't know what you mean. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Tue, Jan 5, 2010 at 7:40 PM, Nop ekkeh...@gmx.de wrote: Real cycleways with official signs are an obstacle to me that I need to avoid. highway=cycleway if and only if it has an official sign...? :P ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Tue, Jan 5, 2010 at 11:30 PM, Richard Mann richard.mann.westoxf...@googlemail.com wrote: ... lets find other tags to make the distinctions we want, and discourage people from reading too much into highway=cycleway (I wouldn't go so far as to deprecate it, just insist that people add tags if they want to convey a more precise meaning). +1. I've made several detailed suggestions in the past, but the usual response is but that's too much typing!. What can do... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Wed, Jan 6, 2010 at 3:34 AM, Alex Mauer ha...@hawkesnest.net wrote: My point is: There is an important difference between - a real, official cycleway (prohibited by law for others) - some way that looks like it was pretty much suitable for cycling ... I would suggest that the difference between tagging for your two examples is most likely legal, and therefore: highway=path+access=no+bicycle=designated for the former and highway=path+bicycle=yes for the latter. Close - but bicycle=yes just means bicycles are legal (http://wiki.openstreetmap.org/wiki/Access). For suitability (whatever that means), I'd suggest bicycle=yes + bicycle:suitable=yes. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Wed, Jan 6, 2010 at 8:02 AM, Alex Mauer ha...@hawkesnest.net wrote: Close - but bicycle=yes just means bicycles are legal (http://wiki.openstreetmap.org/wiki/Access). For suitability (whatever that means), I'd suggest bicycle=yes + bicycle:suitable=yes. In point of fact I would do neither, because I don’t see the need to point out particularly suitable biking routes that aren’t officially designated bike routes. Any way of doing so would be far too subjective for my tastes. But if I really felt a strong need to apply a tag for some reason, it would be bicycle=yes. Yes, I agree with all of that - but remember that bicycle=yes refers to legality only. My point is that if there are some who feel the need to tag suitability, this should be done with a new tag, such as *:suitable=* (as no current tags are documented as referring to suitability - and with good reason). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Wed, Jan 6, 2010 at 10:26 AM, Nick Austin nick.w.aus...@gmail.com wrote: Just to be clear, highway=cycleway is shorthand for highway=footway + bicycle=yes and highway=bridleway is shorthand for highway=footway + horse=yes. There's no need for this definition creep nonsense. BTW, footway is a bad name. If OSM was starting over it I'd suggest that it should be highway=narrowway or similar, used for all ways that are narrower than a track. highway=path precisely fits your definition (in my mind) of narrowway. So, use highway=path + access tags. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Wed, Jan 6, 2010 at 1:01 PM, Steve Bennett stevag...@gmail.com wrote: ... There are lots of shared use paths, and lots of unlabelled paths. I basically want the shared use paths to be tagged as cycleways (because that's the function they serve), and *some* of the unlabelled paths to be tagged as cycleways. Shared path (signed with pedestrian/bicycle symbol): highway=path + foot=designated + bicycle=designated. Unlabelled paths, if you insist: highway=path + bicycle:much_more_suitable_than_average=yes (+ foot=* where applicable) Trouble is, current usage (and renderer support) treats highway=path very differently from highway=footway. It seems to mean walking track with unmade surface. Re: current usage: not true. See e.g. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath/Examples Re: current renderer style sheets: Please file a bug (if there isn't one filed already) for the particular style sheet you are referring to, if you think the rendering isn't appropriate given the descriptions in wiki. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Mon, Jan 4, 2010 at 11:23 PM, Greg Troxel g...@ir.bbn.com wrote: Steve Bennett stevag...@gmail.com writes: After much thought, I think I've finally decided that the definition I would like for cycleway would be something like the way is especially well suited to use by bicycles. The point of a map is to convey something to the user, and so the question is what most people want to know, and how to encode that with a relatively small number of terms. So, I think your definition is something that boils down to would someone call this a bike path or a walkway, but that having a list of properties is helpful. Let me say back to you what you just said: A cycleway is a cycleway if someone would call this a bike path. IMHO that's not helpful. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)
On Tue, Jan 5, 2010 at 12:51 PM, Steve Bennett stevag...@gmail.com wrote: If it's a short path between two buildings or something, I wouldn't call that especially suitable for cycling. Others might. There is a lot of fuzzy area here. This is a problem. It's called unverifiability. And to reiterate, I haven't specified what the minimum standard would be exactly. Please do. I expect you may find it difficult, but I'm hoping to be surprised :) ... It is not important that a single piece of tarmac be mapped the same way in every country. This mindset leads to the situation we currently have - people using the same tag for multiple overlapping purposes. If you want fragmentation of the OSM database according to country, then this is not something I agree with. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed definition for cycleways
On Tue, Jan 5, 2010 at 1:30 PM, Steve Bennett stevag...@gmail.com wrote: If ... every time you saw something mapped as a bike path, it corresponded to something you thought of as a bike path - that would be perfect. Key words: something YOU thought of as a bike path. If everyone thinks of a bike path in exactly the same way as everyone else, that's great. If so, it should be easy for you to write down a specific, verifiable definition that everyone will immediately agree with. I still haven't seen one. But I fear we're about to go down some very old, tired ground here, so Roy, may I suggest you tread carefully :) Yeah. I wouldn't bother, but you seem really enthusiastic to find a solution, as am I. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Thu, Dec 31, 2009 at 1:43 AM, Matthias Julius li...@julius-net.net wrote: So, what is steep then? 15% or more? I personally don't care, because I won't use it. Ask a civil engineer or look at some regulations and choose something meaningful? I would say all the incline tags should be moved to the ways. As Anthony said, this isn't equivalent, unless it's moved to a new way with infinitesimal length. or to a relation that indicates that a way has an incline at a certain node. You could call this overkill, of course, but it has the advantage to be more robust when the data is changed, especially when another way is added to that node. Hmm that's true. This is a very similar idea to the proposed Relation:type=stop, i.e. using a way to indicate direction, and a node to indicate location - and a relation to link the two (http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop) I think Relation:type=stop is an ok idea - so, not surprisingly, I think your Relation:type=incline idea is also ok. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Tue, Dec 29, 2009 at 7:43 PM, Liz ed...@billiau.net wrote: I might be old, I might have gone to school in the Dark Ages, but a point cannot have an incline. An incline is more or less a gradient. From Wikipedia: The gradient of H at a point is a vector pointing in the direction of the steepest slope or grade at that point. A point can have a gradient, and thus an incline. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Wed, Dec 30, 2009 at 3:01 AM, Matthias Julius li...@julius-net.net wrote: If you know the actual incline you can tag it with its value. If you have to estimate it anyway then a hard definition on what is steep is not worth that much anymore. It is a subjective classification - not more and not less. One could think it implies a FIXME: check for actual value. I have no problem with using a FIXME. But performing even a subjective classification still requires criteria as to how to make that classification. I.e. it is steep if __. If you want to define steep by saying, on the wiki, incline=*_steep means the mapper personally thought the incline was steep, go ahead - but IMHO that's not a good definition. What I mean to say is, unless you can think of a better way to tag incline=* on nodes, we should encourage the use of incline=* for this purpose (as opposed to some other tag like inclination=* or steepness=*, or node_incline=* etc., which would just be silly). I would say all the incline tags should be moved to the ways. As Anthony said, this isn't equivalent, unless it's moved to a new way with infinitesimal length. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Mon, Dec 28, 2009 at 10:59 AM, Matthias Julius li...@julius-net.net wrote: Roy Wallace waldo000...@gmail.com writes: Also, incline=* is still mathematically valid for nodes to indicate the instantaneous incline at that point, so I don't see a problem with that. The problem with nodes is that you can't tell to which way the incline applies when there is more than one connecting to the node. You're right. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Tue, Dec 29, 2009 at 3:18 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: but it still is strange to tag a node with a tag the meaning of which depends on a way, isn't it? Or more precisely, depends on a direction. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Tue, Dec 29, 2009 at 10:30 AM, Matthias Julius li...@julius-net.net wrote: ... I would like to add a note to the 'highway=incline|incline_steep' tags on Map Features saying that they discouraged in favor of 'incline=*'. I think there should not be redundant tagging schemes in Map Features. +1 I would also add the values 'up_steep' and 'down_steep' to 'incline=*' for this to be a equivalent replacement of the highway tags. -1. This is like having width=wide - this should be discouraged. I would also like to change 'incline=*' so it does not apply to nodes anymore. But, if there are objections I will hold off on this one. It may be enough to say something like This can be applied to a node only when the node is part of a single way, exclusively (otherwise the direction of incline is ambiguous). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Tue, Dec 29, 2009 at 10:49 AM, Anthony o...@inbox.org wrote: On Mon, Dec 28, 2009 at 7:30 PM, Matthias Julius li...@julius-net.net wrote: Are there any other official node tags that depend on a parent way to be fully defined? ... However, none of them, as far as I know, depend on the *direction* of the way on which they are defined. Well, there's some ideas that refer to this for stop signs: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop Tagging the idea of direction crops up as an outstanding problem from time to time (e.g. mapping roads as areas, stop signs, ...) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
On Tue, Dec 29, 2009 at 11:47 AM, Matthias Julius li...@julius-net.net wrote: 'up/down' is in there to be able to tag an incline where the exact value is not known. Adding '_steep' would allow to differentiate a little. Of course, what is steep and what is not is subjective - just like surface quality. I just don't want to loose any semantics compared to the highway=incline tags. But that's my point - sure, you don't want to lose semantics i.e. meaning. But IMHO steep is *meaningless*. Validators could warn about ambiguous incline tags, though. Yup I think this is the best solution. Unless, of course, nobody *wants* to tag incline=* on nodes :) But assuming they do, they should be able to. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
