Re: [OSM-talk] Tagging schema
2009/10/5 Liz ed...@billiau.net: On Mon, 5 Oct 2009, Mike N. wrote: I recently set out to do an all-inclusive map of a section of town. Perhaps I'm unfortunate enough to live in a city of lawyers, but it seems that a large entire section of town consists of law offices. I can't believe I'm not the first person to want to tag a law office as a shop category (I may have completely missed an existing tag). The process of creating a new tag is laborious: I used shop=solicitor because I had heaps of stuff to put on the map and no time to do any exhaustive search. Any tag I found on the wiki later I adjusted to a generally used one. I'm quite happy to change my tag to shop=lawyer. I'm not an English native speaker, maybe that's why shop=lawyer sounds strange to me. All lawyers that I know of I'd actually consider offices, not shops. I believe that they should be better put in a different category. Or would you also tag shop=architect, shop=energy_provider, shop=doctor, shop=foreign_languages, shop=military_consultant, shop=fire_department, shop=mailorder ? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
I used shop=solicitor because I had heaps of stuff to put on the map and no time to do any exhaustive search. Any tag I found on the wiki later I adjusted to a generally used one. I'm quite happy to change my tag to shop=lawyer. I'm not an English native speaker, maybe that's why shop=lawyer sounds strange to me. That sounds a bit strange even here in the US.What about shop=law_office or shop=legal_services ? All lawyers that I know of I'd actually consider offices, not shops. I believe that they should be better put in a different category. What other categories might work? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Thu, 8 Oct 2009, Martin Koppenhoefer wrote: I'm not an English native speaker, maybe that's why shop=lawyer sounds strange to me. All lawyers that I know of I'd actually consider offices, not shops. I am not discussing the actual tag. I'm discussing the complete ease with which something can be tagged compared to the difficulty of finding the already used or proposed tag. The difficulty of finding a suitable English phrase which is easily understood, not prone to misconceptions and hopefully is acceptable to OSM users I hadn't mentioned. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
2009/10/7 Elizabeth Dodd ed...@billiau.net: On Thu, 8 Oct 2009, Martin Koppenhoefer wrote: I'm not an English native speaker, maybe that's why shop=lawyer sounds strange to me. All lawyers that I know of I'd actually consider offices, not shops. I am not discussing the actual tag. I'm discussing the complete ease with which something can be tagged compared to the difficulty of finding the already used or proposed tag. The difficulty of finding a suitable English phrase which is easily understood, not prone to misconceptions and hopefully is acceptable to OSM users I hadn't mentioned. best way to avoid misconceptions is to write some sentences in the wiki. If you're looking for a feature, you simply type lawyer in the wiki-search-field and get usually an answer. E.g. in this case: http://wiki.openstreetmap.org/wiki/Proposed_features/Lawyer if you don't get an answer: use a custom tag (or better, ask in the list if someone knows a tag you didn't find and step 2 use a custom tag). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Mike N. schrieb: The delay in rendering is irritating but understandable. A sandbox with a limit of a view ways/areas to allow immediate render would be extremely useful. I read somewhere today that someone is working on this - a web site where you'll be able to designate a bounding rectangle with near immediate rendering. I'm working on this as a VirtualBox image. You may still want to use panman's styleedit [1] to play around a little. Peter [1] http://dev.openstreetmap.nl/~panman/styledit/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 05/10/2009, at 7:54 PM, David Earl wrote: * Three new primitives, tagkey for describing the k part of tags, tagvalue for the v part of tags and tagdescription separated off to allow for multiple descriptions in multiple languages without having to download all the data for languages you're not interested in. (tagkey etc can be anything we want, don't get too hung up on the terminology, I just use it for didactic purposes). I'd been thinking something along these lines for a while, due to having used a similar system at an old job. There everything in the database was described my metadata in The Dictionary, and The Dictionary lived in the database too. Essentially, we'd just allow the tagging of tags (keys and values) in the same way that we tag nodes, ways and relations. I think being able to add arbitrary metadata to tags would be handy, because you can come up with cool new things. For example, you could tag the proposed incline=up tag with edit:reverse_way=value_flip or similar, which says the value needs to be flipped if the way is reversed. If an editor knew what to do for that tag it could do it automatically, and if it didn't it could present a warning to the user. Control would be an issue though, as someone accidentally or maliciously breaking tag metadata could really screw things up, if editor and renders went straight off it rather than verified copied. (d) the meaning of newly introduced or changed tags goes along with them, so that the intention is described to others. I can see things getting ickier than they are now if you can just go around adding new shop= values, without having some prior discussion to what it means. If I saw a suggested option in an editor, I would generally assume that there is some agreement as to what it is supposed to mean. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 06/10/2009 13:35, James Livingston wrote: I can see things getting ickier than they are now if you can just go around adding new shop= values, without having some prior discussion to what it means. If I saw a suggested option in an editor, I would generally assume that there is some agreement as to what it is supposed to mean. You can already add new shop values willy nilly with no discussion, and lots of people do (and value this capability and would be loathe to give it up). I hope that when this happens in the future (a) the editor would already know what other people have used, so you'd be able to see immediately whether the first person to previously see a joke shop (say) labelled it shop=joke or shop=jokes and you can follow suit rather than inventing a similar tag (or if you are perverse or don't like the one they chose, you can introduce a new one and mark one of them a synonym of the other so a renderer can know about both without any recoding), or if none you can add your own, and (b) you are aware you are doing this and it is not just a spelling error. The action to add a new tag/value ought still to be simple in an editor, so you're not held up for lack of anyone adding shop=joke previously, but it should at least ask you to describe what you mean so you can spread the word and at least minimally document your tag. (Of course, you could code an editor to bypass all of this, but that would be rather unhelpful to everyone else). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 06/10/2009, at 10:58 PM, David Earl wrote: On 06/10/2009 13:35, James Livingston wrote: I can see things getting ickier than they are now if you can just go around adding new shop= values, without having some prior discussion to what it means. If I saw a suggested option in an editor, I would generally assume that there is some agreement as to what it is supposed to mean. You can already add new shop values willy nilly with no discussion, and lots of people do (and value this capability and would be loathe to give it up). Sure, and I uses that all the time. I was just trying to say that I think a lot of people (myself included) would tend to assume that suggestions being offered by an editor had at least some vaguely consistent meaning, which a lot of the shop tags don't. The action to add a new tag/value ought still to be simple in an editor, so you're not held up for lack of anyone adding shop=joke previously, but it should at least ask you to describe what you mean so you can spread the word and at least minimally document your tag. (Of course, you could code an editor to bypass all of this, but that would be rather unhelpful to everyone else). I think that being able to document your tag would be useful, even (or especially) when someone else has already done so. It would allow us to collect more data about how people are actually using the tags, and might help to find things that need to be ironed out. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Joseph Booker wrote: On Mon, 5 Oct 2009 11:02:05 +1100 Liz ed...@billiau.net wrote: On Mon, 5 Oct 2009, Joseph Booker wrote: Not sure if you are trolling or just not aware of the wiki, but I'll give the benefit of the doubt and assume the latter. I wouldn't say that this guy is trolling at all, but has put a lot of thought into his mail. I don't find your quick answers helpful to myself, who is interested to see a way forward from these discussions, not sideways or backwards. Figured a sideways look would help for perspective. Just wanted to make clear that there is an accepted schema, which may not be as strictly enforced as the original poster would like but matches most of his thoughts. The similarity of his ideas with the way things are currently run (excluding the classes of tags based on what kind of values they accept) with the obvious desire for controlling clients is what made me think this was trollish, but like I said, I'm just going to assume he was unaware of the wiki and the procedures done there to formalize the tags in the database. Egil, sorry if I came off as rude. I just think your email not accounting for the wiki serving (maybe ineffectively, that is another discussion) the purpose of your strict tagging mail group reflects some misunderstandings. If I am wrong, please let me know and I would be happy to offer comments on your proposal itself. Actually - I think Egil's email packages up completely what IS missing from even the wiki ... As soon as you ARE looking to add detail, the wiki collapses into something of a free for all? His idea for a table of keys with their details is something I've been advocating for a long time, and *IS* essential to add a level of compatibility once you actually allow multi-lingual use of the tools. ( Simply replacing long English strings with a unique numeric tag IN the data would then be the natural way to compact the core data without affecting any of the detail! ) YES the wiki has the basics, but if English is not a language you easily understand, then the 'translations' where they do exist are not particularly consistent with the basic English 'rules' ( at least that is my understanding - based on feedback - since I even have trouble with English sometimes ;) ) ( Egil - a little aside, while a check box for boolean would be nice, there is still an element of 'NULL' - that is in addition to setting a boolean tag, one still needs to decide if it should or should not be present ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Egil Hjelmeland wrote: OSM is a community of volunteers. So neither bureaucracy or dictatorship is probably the way to go. I would guess that forking off a “tagging” mail group with a strict “keep-to-topic” policy would be the way to proceed. I've asked for a tagging mailing list to be set up and have offered to administrate it. On a more general level, the issue with freeform tags isn't so much that they need replacing per se, but that the documentation, as almost everywhere in OSM, is shockingly bad. When you say I DO NOT WANT TO SEARCH TALK-MAIL ARCHIVES TO LEARN HOW TO TAG! that's a failing of the documentation, not of the way in which tags are introduced into circulation. In actual fact we _do_ converge on most tags. This whole yes/true/1 malarkey is no issue at all. foot=yes outnumbers foot=1 by 56610:1 (really), building=yes outnumbers building=true by 135:1, and even with the oneway tag (where '1' has some historical currency because early editors couldn't reverse the direction of a way, so 1/-1 was more common), oneway=yes outnumbers oneway=1 by 10:1. As Matt's graph shows, =yes is increasing in dominance, too. Potlatch has always used =yes and the josm-dev archives suggest that JOSM switched from =true to =yes last year. Pretty much the only significant area of disagreement I can think of right now is footway vs path, and even that's less a confict, more TMTOWTDI. cheers Richard -- View this message in context: http://www.nabble.com/Tagging-schema-tp25743250p25746268.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, October 5, 2009 15:36, Lester Caine wrote:
snip
( Egil - a little aside, while a check box for boolean would be nice,
there is still an element of 'NULL' - that is in addition to setting a
boolean tag, one still needs to decide if it should or should not be
present )
Checkboxes these days /can/ represent three states. There are usually two
states: checked (or ticked) and not checked (an empty white box). In most
GUIs it is possible to represent a third state, perhaps a grey square
filling the box. (This is different from the control being disabled,
usually shown by being greyed-out). The meaning of this third state
depends on the application, but it can mean NULL, unknown, conflicting
source data, or whatever you want it to mean when it's not True or False.
I'm not sure that this third state is particularly useful or intuitive,
but I know it means something different to True or False when I see it.
I like the Japanese style of conveying information like this. A cross
('X', often red) means 'no', 'none', 'wrong', 'false', or 'not'. A circle
('O', often green) means 'yes', 'correct', 'available', 'OK', or 'true'.
A triangle (hmm, can't do that in ASCII) means 'maybe', 'limited',
'restricted', 'perhaps'. Obviously their meanings depend on context, but
they are well-known in Japan (and not too confusing outside of Japan).
In fact, here's a handy-dandy reference:
http://japanesetranslator.co.uk/portfolio/playstation-symbols/
(The use of 'playstation' is incidental to the article).
Andrew
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Andrew Errington wrote: On Mon, October 5, 2009 15:36, Lester Caine wrote: snip ( Egil - a little aside, while a check box for boolean would be nice, there is still an element of 'NULL' - that is in addition to setting a boolean tag, one still needs to decide if it should or should not be present ) Checkboxes these days /can/ represent three states. There are usually two states: checked (or ticked) and not checked (an empty white box). In most GUIs it is possible to represent a third state, perhaps a grey square filling the box. (This is different from the control being disabled, usually shown by being greyed-out). The meaning of this third state depends on the application, but it can mean NULL, unknown, conflicting source data, or whatever you want it to mean when it's not True or False. I'm not sure that this third state is particularly useful or intuitive, but I know it means something different to True or False when I see it. Your missing the point Andrew - we need to be able to 'switch the tag on or off' as in Add it or not to the current object. We would not expect every 'boolean' tag to be presented, so need to be able to select it, and then also delete it again if appropriate. In my terms 'NULL' just means not present at all, but if it was a tag that has a default interpretation, then it may be added automatically anyway? But need not be present to flag it's default state. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 05/10/2009 00:12, Egil Hjelmeland wrote: As a mapper, I want a much more structured, well defined tagging scheme. Steve started a discussion on the dev list in which I proposed just such a scheme/schema. Since there's been several discussions on talk healding in this direction, I'll send it here too: I would like to go further than Steve proposes, but I understand it is a hard sell to the anarchist wing of OSM while being welcome to the conformist wing. But I really think what I outline below treads a middle way. I'm absolutely not proposing to restrict anyone's freedom to add new tags or values. I think it would be really helpful to bring together the tag definitions into one place, *in the database and API itself*. I mean a complete schema: the tags, their possible values, their descriptions (in multiple languages), their equivalences both in other languages and synonyms, their related tags (in essence properties of the main descriptive tag, hence oneway=... with highway=...), deprecations and so on. And I think this gets changed as other objects in the database get changed: freely but consciously. So if there is a new value for shop, it is a conscious act to add that to the list of values for shop, and to describe it, not just casually adding it as a tag value. Let me be quite clear again: this doesn't restrict anyone's freedom to add new tags or values. Anyone can edit them just like the map data. It does make it a little more work, but the value of doing so both to the person making the change and the rest of the community is also increased: (a) the tag/value is publicised, not buried in the map data, so if it is a good one, it is more likely to be adopted. For example, take landuse=orchard discussed recently. I've tagged at least three areas with landuse=orchard in the last 3 years. I just did it. Others may have used land=orchard, whatever. However, it would only be obvious I'd done this if the renderers knew about it or I'd made a song and dance about it. With a central schema, it would automatically be possible for it to appear on editor menus for example. (b) if we choose to check data against this schema, spelling mistakes would be eliminated (not in names and other naturally free form data, obviously) (c) editor and consumer programs can all work off the same schema: presets and menus of values are table driven and in sync, renderers know the possible things they might want to render (not that they have to of course) and can see automatically that highway=gate and barrier=gate are the same thing (or indeed barriere=tor or barrière=porte). (d) the meaning of newly introduced or changed tags goes along with them, so that the intention is described to others. Editors can offer help. Renderers can offer legends. Here's the kind of thing I had in mind: * Three new primitives, tagkey for describing the k part of tags, tagvalue for the v part of tags and tagdescription separated off to allow for multiple descriptions in multiple languages without having to download all the data for languages you're not interested in. (tagkey etc can be anything we want, don't get too hung up on the terminology, I just use it for didactic purposes). In the following, the fields could be key/value pairs, i.e. tags themselves, or separate named fields in the database depending on how things need to be indexed. But allowing the schema to itself have tags means it is extensible. Perhaps it can even be self-describing. tagkey name = [tagkey] type = text | scalar | real | integer | boolean | value where... text: any arbitrary string scalar: a number possibly qualified by some units real: a floating point number integer: an integer boolean: vlues such as 'yes', 'true', '1', 'no', 'false', '0' value: a value chosen from among a specific set of strings documented by the tagvalue object units = [semicolon separated list of possible units] defaultunits = [one from the units list] appliesto = [semicolon separated list of tagkey or tagkey=tagvalue] indicates this tag is usually used as a property qualifying the given tags relevantto = area | node | way | relation tagvalue name = [tagvalue] appliesto = [tagkey] relevantto = area | node | way | relation photo[:N] = [url] !-- allows for more than one photo, photo:1 etc -- synonym = [tagkey or tagkey=tagvalue] seealso = [tagkey or tagkey=tagvalue] tagdescription lang = [languagecode] appliesto = [tagkey or tagkey=tagvalue] plus a description in that language (not a tag value) For example tagkey name='barrier' type='value' / tagvalue name='gate' appliesto='barrier' relevantto='node' / tagvalue name='bollard' appliesto='barrier' relevantto='node' / tagvalue name='bollards' appliesto='barrier' relevantto='node' synonym='bollard'/ tagdescription
Re: [OSM-talk] Tagging schema
2009/10/5 Andrew Errington a.erring...@lancaster.ac.uk: On Mon, October 5, 2009 15:36, Lester Caine wrote: snip ( Egil - a little aside, while a check box for boolean would be nice, there is still an element of 'NULL' - that is in addition to setting a boolean tag, one still needs to decide if it should or should not be present ) Checkboxes these days /can/ represent three states. There are usually two states: checked (or ticked) and not checked (an empty white box). In most GUIs it is possible to represent a third state, perhaps a grey square filling the box. (This is different from the control being disabled, usually shown by being greyed-out). The meaning of this third state depends on the application, but it can mean NULL, unknown, conflicting source data, or whatever you want it to mean when it's not True or False. I'm not sure that this third state is particularly useful or intuitive, but I know it means something different to True or False when I see it. in JOSM-Preset there are indeed three states: yes, no and notset. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
2009/10/5 Egil Hjelmeland pri...@egil-hjelmeland.no: Every key should be assigned a type (or class). Could be: - boolean - enumeration - numeric - string - free text. Boolean is yes/no. Editor tools should present a Boolean key as a checkbox. there is IMHO no boolean values in OSM. Feel free to give counter examples. Highways (I guess you're talking about ref-tag) aren't enumerated either (they used to be dependant on national enumeration, but nowadays there is even official refs like SP ex SS 527). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
David Earl david at frankieandshadow.com writes: I think it would be really helpful to bring together the tag definitions into one place, *in the database and API itself*. I mean a complete schema: the tags, their possible values, their descriptions (in multiple languages), their equivalences both in other languages and synonyms, their related tags (in essence properties of the main descriptive tag, hence oneway=... with highway=...), deprecations and so on. +1. And I think this gets changed as other objects in the database get changed: freely but consciously. So if there is a new value for shop, it is a conscious act to add that to the list of values for shop, and to describe it, not just casually adding it as a tag value. Ideally, there would be some kind of prompt or reminder: you recently tagged a node with shop=antiques; if this was intentional, please go to whatever/tags/shop and add the new value with a description. Or, you recently tagged a node with shop=literature, but the database (visible at whatever/tags/shop/literature) suggests that this is deprecated in favour of shop=bookshop. Perhaps you would like to change it? -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009, Martin Koppenhoefer wrote: there is IMHO no boolean values in OSM. Feel free to give counter examples. The arguments for how to tag a footway and a cycleway contain a number of boolean examples. Either you are permitted to drive a car down the footway, or you are not. You are permitted to cycle on the footway, or you are not. The trinary response from my culture would be it's only a problem if you are caught. no_exit is boolean until we consider flying as a possibility and the tags needed for certain Australian road conditions dry_weather_only and 4wd_only are certainly boolean. so having dealt with boolean, and discussed enumeration (house numbers) do you have any further suggestions after numeric, string and free text? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
David Earl wrote: I think it would be really helpful to bring together the tag definitions into one place, *in the database and API itself*. I mean a complete schema: the tags, their possible values, their descriptions (in multiple languages), their equivalences both in other languages and synonyms, their related tags (in essence properties of the main descriptive tag, hence oneway=... with highway=...), deprecations and so on. And I think this gets changed as other objects in the database get changed: freely but consciously. So if there is a new value for shop, it is a conscious act to add that to the list of values for shop, and to describe it, not just casually adding it as a tag value. +100% Let me be quite clear again: this doesn't restrict anyone's freedom to add new tags or values. Anyone can edit them just like the map data. It does make it a little more work, but the value of doing so both to the person making the change and the rest of the community is also increased: Until such time as agreement is made to restrict some tags, there is nothing to stop free format text as at present, but having a list of agreed values - and presenting them in the correct local language - can only be a good thing? (a) the tag/value is publicised, not buried in the map data, so if it is a good one, it is more likely to be adopted. For example, take landuse=orchard discussed recently. I've tagged at least three areas with landuse=orchard in the last 3 years. I just did it. Others may have used land=orchard, whatever. However, it would only be obvious I'd done this if the renderers knew about it or I'd made a song and dance about it. With a central schema, it would automatically be possible for it to appear on editor menus for example. Using an agreed set of landuse tags and having on-line links to help relating to the values makes sense, and again they an be mapped internally to other languages (b) if we choose to check data against this schema, spelling mistakes would be eliminated (not in names and other naturally free form data, obviously) Behind the scenes local language tags can be added automatically. (c) editor and consumer programs can all work off the same schema: presets and menus of values are table driven and in sync, renderers know the possible things they might want to render (not that they have to of course) and can see automatically that highway=gate and barrier=gate are the same thing (or indeed barriere=tor or barrière=porte). My own preference internally would be for simple numeric tags - but then I work in 'real' relational databases where mapping appropriate text when displaying the user view is natural. XML is not really designed with language translation in mind :( (d) the meaning of newly introduced or changed tags goes along with them, so that the intention is described to others. Editors can offer help. Renderers can offer legends. And rendering rules could be enhanced by being able to select the preferred elements that a particular map requires. Here's the kind of thing I had in mind: * Three new primitives, tagkey for describing the k part of tags, tagvalue for the v part of tags and tagdescription separated off to allow for multiple descriptions in multiple languages without having to download all the data for languages you're not interested in. (tagkey etc can be anything we want, don't get too hung up on the terminology, I just use it for didactic purposes). In the following, the fields could be key/value pairs, i.e. tags themselves, or separate named fields in the database depending on how things need to be indexed. But allowing the schema to itself have tags means it is extensible. Perhaps it can even be self-describing. tagkey name = [tagkey] type = text | scalar | real | integer | boolean | value where... text: any arbitrary string scalar: a number possibly qualified by some units real: a floating point number integer: an integer boolean: vlues such as 'yes', 'true', '1', 'no', 'false', '0' value: a value chosen from among a specific set of strings documented by the tagvalue object units = [semicolon separated list of possible units] defaultunits = [one from the units list] appliesto = [semicolon separated list of tagkey or tagkey=tagvalue] indicates this tag is usually used as a property qualifying the given tags relevantto = area | node | way | relation tagvalue name = [tagvalue] appliesto = [tagkey] relevantto = area | node | way | relation photo[:N] = [url] !-- allows for more than one photo, photo:1 etc -- synonym = [tagkey or tagkey=tagvalue] seealso = [tagkey or tagkey=tagvalue] tagdescription lang = [languagecode] appliesto = [tagkey or tagkey=tagvalue] plus a description in that language (not
Re: [OSM-talk] Tagging schema
2009/10/5 Liz ed...@billiau.net: On Mon, 5 Oct 2009, Martin Koppenhoefer wrote: there is IMHO no boolean values in OSM. Feel free to give counter examples. The arguments for how to tag a footway and a cycleway contain a number of boolean examples. Either you are permitted to drive a car down the footway, or you are not. You are permitted to cycle on the footway, or you are not. The trinary response from my culture would be it's only a problem if you are caught. no_exit is boolean until we consider flying as a possibility still there are other values like unknown and motor_vehicle which seem to make sense to me (I didn't add them myself, as I consider noexit (no_exit is used just 5 times, so I guess we're talking about noexit) pointless: that's what a map is for, a router won't need this tag, and in the end the whole earth is noexit, until we consider rockets or other spacecraft a possibility) so having dealt with boolean, and discussed enumeration (house numbers) do you have any further suggestions after numeric, string and free text? even housenumbers can be all kind of weird numbers, so limiting the possibilities doesn't really meet the needs. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 05/10/2009 11:43, Lester Caine wrote: Rather than all these separate elements, tag values should form part of the tagkey object, and descriptions can be added at any level. I need to find the link to a good example, but tag name='barrier' type='value' relevantto='node' tagvalue name='gate' / tagvalue name='bollard'/ tagvalue name='bollards'/ description lang='en'one or a series of short posts for excluding or diverting motor vehicles from a road, lawn, or the like/decription tag/ But I suspect this is just a misunderstanding, as a scheme needs to be defined in .xsl. http://www.cabinetoffice.gov.uk/media/260545/BuildingStructure.xml is a good example of a definition of a building with enumerated tag values. I was trying to find the one that goes with 'landuse' but I don't have time ... need to be on the road by 1 ... You're probably right - this was only a first attempt at suggesting the principle. In practice, the actual representation would be as database tables, and this gets exposed through the API as XML. I would think the values would typically be in a separate table, which is why I wrote it the way I did, but the API doesn't have to deliver it separately as I wrote it. I think you'd still want to be able to filter descriptions and possibly other aspects by selected language to limit the size, but that's a minor detail. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
And I think this gets changed as other objects in the database get changed: freely but consciously. So if there is a new value for shop, it is a conscious act to add that to the list of values for shop, and to describe it, not just casually adding it as a tag value. Let me be quite clear again: this doesn't restrict anyone's freedom to add new tags or values. Anyone can edit them just like the map data. It does make it a little more work, but the value of doing so both to the person making the change and the rest of the community is also increased: (a) the tag/value is publicised, not buried in the map data, so if it is a good one, it is more likely to be adopted I recently set out to do an all-inclusive map of a section of town. Perhaps I'm unfortunate enough to live in a city of lawyers, but it seems that a large entire section of town consists of law offices.I can't believe I'm not the first person to want to tag a law office as a shop category (I may have completely missed an existing tag). The process of creating a new tag is laborious: Search the wiki for approved tags that don't appear in presets Search the wiki for a proposed tag to be able to at least choose a more common tag Search TagWatch - I didn't play with this for long, but the links from the wiki to TagWatch don't make it easy to query a list of tags in use for key shop for example. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 05 Oct 2009 12:25:37 +0100 Lester Caine les...@lsces.co.uk wrote: I think though - we need to define a proper xsl schema wjich can be used WITH the tag data :( OK, benefit of the doubt goes out the window at this point. If you are going to say you hate XML with any credibility, you need to know that there is no such thing as an XSL schema. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 05 Oct 2009 01:12:41 +0200 Egil Hjelmeland pri...@egil-hjelmeland.no wrote: I started mapping my local mountain village in Norway a month ago. I find the fundamental OSM data model very simple and elegant: The three basic elements (node, way/area, relation), and properties as key-value pairs. But I don’t like that free-form tagging has been elevated to a Religion. As a mapper, I want a much more structured, well defined tagging scheme. I'm late saying this. I think your proposal is thorough, workable and well stated. Thank you – you went to places I am afraid to even dare think, so inculcated am I. I am not sure I have seen anything compelling in the thread to challenge or add to what you have said. I'm afraid I have nothing to add but support because it's exactly what I would like to see happen. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009, Mike N. wrote: I recently set out to do an all-inclusive map of a section of town. Perhaps I'm unfortunate enough to live in a city of lawyers, but it seems that a large entire section of town consists of law offices.I can't believe I'm not the first person to want to tag a law office as a shop category (I may have completely missed an existing tag). The process of creating a new tag is laborious: Search the wiki for approved tags that don't appear in presets Search the wiki for a proposed tag to be able to at least choose a more common tag Search TagWatch - I didn't play with this for long, but the links from the wiki to TagWatch don't make it easy to query a list of tags in use for key shop for example. I used shop=solicitor because I had heaps of stuff to put on the map and no time to do any exhaustive search. Any tag I found on the wiki later I adjusted to a generally used one. I'm quite happy to change my tag to shop=lawyer. You have described an interesting example of the difficulties of wishing to be a conformist on OSM and I have described the example of how easy it is to be an anarchist. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
You have described an interesting example of the difficulties of wishing to be a conformist on OSM and I have described the example of how easy it is to be an anarchist. The only reason for wanting to be a conformist is the possibility for more meaningful rendering sooner. Currently, shop=xyz on a node, where xyz is unknown, results in no name rendering on Mapnik. So, I've revised my approach to placing non-rendering shop types on the building outline where the name= tag will be shown. Previously, I had preferred the lone node inside a building outline so that new people can more easily spot buildings that have not been identified, then they can drop a POI icon without resulting in duplicate name rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Mike N. wrote: So, I've revised my approach to placing non-rendering shop types on the building outline where the name= tag will be shown. If I understand you correctly your mapping/tagging so the name is displayed along the outline of the shop. unknown boundaries also do this. I believe this is considered an error in Mapnik which is known about. I think(?) a fix is being work on. I'm sure a mapnik programmer could give more accurate info. Personally I don't like the way the name wraps around corners making it almost impossible to read. That's why I don't map for the render try wait patiently for them to catch up Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
So, I've revised my approach to placing non-rendering shop types on the building outline where the name= tag will be shown. If I understand you correctly your mapping/tagging so the name is displayed along the outline of the shop. I add a building=yes which renders the building footprint, and also eliminates the name wrapping around the corners. Personally I don't like the way the name wraps around corners making it almost impossible to read. I try to add something with 'substance' - landuse, etc to eliminate the name wraps. That's why I don't map for the render try wait patiently for them to catch up I find it difficult to be a monk who labors away at a mountain of XML that may see the light some day. I also like to show people what I am working on - it doesn't need to be fancy, but I also use it to double check my work. Just as reading your essay in reverse helps you catch errors, so does looking at recent work in one form of rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Mike N. wrote: I find it difficult to be a monk who labors away at a mountain of XML that may see the light some day. I also like to show people what I am working on - it doesn't need to be fancy, but I also use it to double check my work. Just as reading your essay in reverse helps you catch errors, so does looking at recent work in one form of rendering. I agree with you. It fustrating to have to do it trial by error never knowing if the taggin is incorrect or the render doesn't accept the values yet. The delay in rendering is irritating but understandable. A sandbox with a limit of a view ways/areas to allow immediate render would be extremely useful. Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
The delay in rendering is irritating but understandable. A sandbox with a limit of a view ways/areas to allow immediate render would be extremely useful. I read somewhere today that someone is working on this - a web site where you'll be able to designate a bounding rectangle with near immediate rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, Oct 5, 2009 at 8:01 PM, Mike N. nice...@att.net wrote: The delay in rendering is irritating but understandable. A sandbox with a limit of a view ways/areas to allow immediate render would be extremely useful. I read somewhere today that someone is working on this - a web site where you'll be able to designate a bounding rectangle with near immediate rendering. I don't see much of a rendering delay with Mapnik... the last few changesets I've uploaded have shown up on the Mapnik layer within 5 minutes. If it's not showing up for you, make sure you clear your cache (control+reload or shift+reload depending on browser should help, too). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Ian Dees wrote: I don't see much of a rendering delay with Mapnik... the last few changesets I've uploaded have shown up on the Mapnik layer within 5 minutes. I think it depends greatly on the time of day maybe where you are in the world. Does anyone know if the servers are all in one place? Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, Oct 5, 2009 at 8:21 PM, Dave F. dave...@madasafish.com wrote: Ian Dees wrote: I don't see much of a rendering delay with Mapnik... the last few changesets I've uploaded have shown up on the Mapnik layer within 5 minutes. I think it depends greatly on the time of day maybe where you are in the world. Does anyone know if the servers are all in one place? The servers [0] are all in the same spot. [0] http://wiki.openstreetmap.org/wiki/Servers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging schema
I started mapping my local mountain village in Norway a month ago. I find the fundamental OSM data model very simple and elegant: The three basic elements (node, way/area, relation), and properties as key-value pairs. But I don’t like that free-form tagging has been elevated to a Religion. As a mapper, I want a much more structured, well defined tagging scheme. - When I use a key, I want to know precisely what type of value is expected. - When I have entered a tag, I want to see in the editor immediately whether the tagging is valid according to approved rule, proposed rule, or not according to anything at all. - When I spend time mapping, I want to know that the data I enter is useful, and can be used for rendering, for route planning, and for future interactive maps. Clearly tags must be according to a structure if that is going to happen. - I want the editor tools to support and enforce the tagging structure. - I want that the tagging dialogs for editor tools can be easily localised to different languages, attracting non-English speaking mappers. Because I think more mappers will increase the probability for success for OSM, and hence increase my own motivation. - I DO NOT WANT TO SEARCH TALK-MAIL ARCHIVES TO LEARN HOW TO TAG! I think the tagging schema should be formally described. It should be a pragmatic mix of strict encoded values and free text values. It must of course be based on the existing (but loosely defined) tagging structure. The tagging structure must be represented as tables in the OSM database, along with a XML API. Of course, such a scheme will not do away with the problem of classifying real world things. It will always be cases where it is difficult to classify what you se as a track or as a road, as a service road or as unclassified road, and so on. And making the Grand Unified Hierarchy will always fail at some places. But once I have selected an option, I want to know that it has a well defined meaning in the OSM System. Some ideas from the top of my head: Data types: Every key should be assigned a type (or class). Could be: - boolean - enumeration - numeric - string - free text. Boolean is yes/no. Editor tools should present a Boolean key as a checkbox. Many of the existing tags fall into enumeration. “highway” is a enumeration. An enumeration may often include a “unclassified” value (e.g. building=yes). Editor tools should present an enumeration as a listbox of some sort. The defined values should be stored in the OSM database. It should be possible to enter new values, but then the system should prefix the value with “proposed:” If proposed values are approved later, then administrator can remove the “proposed:” prefix globally. Idea editor tool: Approved values marked green, previously proposed values yellow, other value is red. Numeric is a decimal number. Editor tools should enforce digits only. Subclasses may be useful: Numeric:meters, numeric:kilometres, numeric:currency. Currency obviously need special handling. A toll fee should always specify what currency is referred. String is typical like name, address, house number. Editor tools should present a single line text input. Telephone numbers, URIs, Wikipedia references may be modelled as a string, or as separate classes, or as subclasses of a string, to be discussed. Language versions may sometimes exist. Free text is end-user-description, mapper-note etc. More or less complete sentences. Language versions may often exist. Editor tools should present a multiline, scrollable text input. Comment BTW: Tag-typing can make tag-use-statistics more to the point: Statistics on the most used enumeration values is useful. Most used phone numbers/street names are less useful… I think a multilevel key scheme should be formalised. ‘:’ seems to be a de-facto standard. Special purpose mapping should use a sub-key-space. Hiking, climbing, ornithology, agriculture, archaeology and so on are examples of special interest groups which should be assigned their own toplevel tag, to be defined by special interest groups. Some generic sub-level keys should be predefined for every key. Like “note”, “description”, “source”, “fixme”. For example: key “ele” may have “ele.source”=”GPS”. “highway”=”cycleway” may have “highway:description”=”Sign says so, but lots of sharp bends and rough edges” (which can be said about 98.5% of Norwegian cycleways). Editor tools should allow entering informal information in addition to every formal key-value pairs, but in a structured way. Database: In the OSM database/API there should be a table on keys: - Key name - Key type/class - Short description in English (authorative) - Optionally a png/svg of the rendering A language translation table on keys: - Key name - Language ID (ISO 639) - Localised description A table of literal values - Key name - Literal value - Short description in English (authorative) - Optionally a png/svg of the
Re: [OSM-talk] Tagging schema
On Mon, 05 Oct 2009 01:12:41 +0200 Egil Hjelmeland pri...@egil-hjelmeland.no wrote: [A lot of stuff here] Short answer to a long mail: http://wiki.openstreetmap.org/wiki/Map_Features and http://wiki.openstreetmap.org/wiki/No:Map_Features (even with approved, proposed, rejected, etc prefixes). Not sure if you are trolling or just not aware of the wiki, but I'll give the benefit of the doubt and assume the latter. http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Validator does some of the things you are looking for too. “highway”=”cycleway” may have “highway:description”=”Sign says so, but lots of sharp bends and rough edges” The note= key is more for this, because this message is more for other mappers and taggers. At least, that is how I interpret the wiki description. -- Joseph Booker signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009, Joseph Booker wrote: Not sure if you are trolling or just not aware of the wiki, but I'll give the benefit of the doubt and assume the latter. I wouldn't say that this guy is trolling at all, but has put a lot of thought into his mail. I don't find your quick answers helpful to myself, who is interested to see a way forward from these discussions, not sideways or backwards. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009 11:02:05 +1100 Liz ed...@billiau.net wrote: On Mon, 5 Oct 2009, Joseph Booker wrote: Not sure if you are trolling or just not aware of the wiki, but I'll give the benefit of the doubt and assume the latter. I wouldn't say that this guy is trolling at all, but has put a lot of thought into his mail. I don't find your quick answers helpful to myself, who is interested to see a way forward from these discussions, not sideways or backwards. Figured a sideways look would help for perspective. Just wanted to make clear that there is an accepted schema, which may not be as strictly enforced as the original poster would like but matches most of his thoughts. The similarity of his ideas with the way things are currently run (excluding the classes of tags based on what kind of values they accept) with the obvious desire for controlling clients is what made me think this was trollish, but like I said, I'm just going to assume he was unaware of the wiki and the procedures done there to formalize the tags in the database. Egil, sorry if I came off as rude. I just think your email not accounting for the wiki serving (maybe ineffectively, that is another discussion) the purpose of your strict tagging mail group reflects some misunderstandings. If I am wrong, please let me know and I would be happy to offer comments on your proposal itself. -- Joseph Booker signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging schema for farms
Hello all, I've got to the point in my local area [1] where most of the roads etc. are mapped and now I'd like to start fleshing out the local countryside. Now, since a huge amount of the countyside is farmland I've been lookin into how to best tag it. However, currently we are somewhat lacking a decent set of tags. There's pretty much only landuse=farm being used at the moment and even then it seems to be used differently by different people (some use it to mark the farm houses, some the surrounding area, some to mark the extent of the fields etc. [7]). Recently, there has been a number of proposals for new ways to tag farms [2,3,4] but none of them seem to have been able to reach a consensus since they all focus on a small part of the picture. What I'd like to do is get the feel for what people want from a farm tagging scheme from this list and then put together a decent, coherent proposal to get this sorted out - once and for all. Now, the way I see it, we need to be able to tag the following: a) Farm house area (this seems to be what landuse=farm is really designed for) b) Farm buildings (this is covered by the building= tag now. Hence [4] is redundant) c) Individual fields with: c 1) Field types. That is animal or crop. See [2] for discussions so far. c 2) Animal type or crop type d) Field boundaries. These are very useful for walkers but are only easily mapped with good aerial imagery. This has been mentioned by many people [5] but nothing seems to have come of it as yet [6]. Personally, I think that (d) is the most important to sort out. It should be a linear way and not an area. My current thoughts are to use landuse=farm for (a) and boundary=fence or boundary=field for (b). As for the (c)s, perhaps a landuse= or an agriculture= tag? What do people think? Regards, Matt Williams [1] http://openstreetmap.org/?lat=50.9112lon=-1.0053zoom=13layers=B0FT [2] http://wiki.openstreetmap.org/index.php/Proposed_features/Crop [3] http://wiki.openstreetmap.org/index.php/Proposed_features/agricultural_Field [4] http://wiki.openstreetmap.org/index.php/Proposed_features/Farmyards,_farm_buildings [5] http://lists.openstreetmap.org/pipermail/talk/2007-January/010105.html [6] http://etricceline.de/osm/united-kingdom/en_stats_boundary.htm [7] http://etricceline.de/osm/united-kingdom/en_combination_landuse=farm.htm signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tagging schema for farms
Just thinking off the top of my head, it would be useful to be able to tag: perminant irregation booms dug outs feed lots (and maybe predominant wind direction ;-) Cheers, Mungewell. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
