Re: [Tagging] Source tag - deprecated for use on objects?
(Replying to the entire conversation thread)
The way I see it: No data about the objects themselves should be in
changeset description - changeset should only describe the *change*
itself. Because - at least to me, but I do expect to many others as
well - it makes the database structure more clear and intuitive.
Even though source tag is metadata, it's still data about the objects.
I sort of agree that metadata doesn't belong on objects. Or maybe it
should at least have some header differentiating it from actual data
(meta:source). But having data about objects stored on changesets is
still worse.
Source tag does indeed have described problems of specificity
(bing;survey;knowledge - which is for which tag) - but these are
mostly edge cases, and a lot of other things in OSM have very similar
problems, and still manage to be very useful in most cases. What needs
to be kept in mind is the *usual* cases where the information is
useful: when I see a feature on OSM that conflicts with what I would
edit there, source tag gives me at least some understanding on which
information is more correct. E.g. when correcting a way to match Bing
imagery or GPS trail, source=landsat is a very different case to
source=survey. Or when changing a name, source=knowledge is very
different from no source tag at all.
Disclaimer: Not attempting to force my way of thinking on anyone, just
providing my viewpoint on the subject for the discussion.
On 2 January 2013 14:50, dies38...@mypacks.net wrote:
I have been told ( on the talk-US email list ) that use of {{key|source}} on
objects has been deprecated for years and that such information is only of
historical interest and its use should be restricted to changesets.
--
- Ilari Kajaste -
E-Mail: ilari.kaja...@iki.fi
WWW: http://iki.fi/ilari.kajaste
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
[Tagging] The OSM philosophy (was: Carriageway divider)
On 26 August 2012 10:42, Markus Lindholm markus.lindh...@gmail.com wrote: We're not supposed to map for the renderer nor the router. Exactly for whom are we to map? For nothing, and no one. Which also means: for anything, everything and all. The OSM approach - as I understand it - is to collect data about reality in best way possible, and let the use of that data come afterwards. Let the renderers, routers and whatnot determine how they can best utilize the data. The reasoning behind that is this: If we map focusing on one single case, or even multiple cases, we set ourselves up for bad data that just happens to produce the right result in the case we're looking at. This easily leads to the data becoming unusable for anything else. If we instead map for no particular case, just trying to model reality in best way possible, we might not see any end result immediately, but the data is left intact, in good quality for any emergent uses we're not even thinking about yet. I think it's a very, very good approach. Uses come and go, but the data is what matters, in the end. It's the data itself, the modelling of reality, we need to focus on. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] drinkable vs. drinking_water
On 13 July 2012 05:35, Andrew Errington erringt...@gmail.com wrote: Anyway, I don't think we should assume other people are stupid and choose 'simple' words just for the sake of it. It seems that we all know what potable means, but we are worried that other mappers, whom we have never met, won't understand. Let me assure you, they are just as smart as you. No. (And please don't equate knowing words with being smart. Especially don't do it for the purposes of twisting the opposing arguent to imply something it doesn't imply. That's just empty rhetorics.) Anecdote: My English is excellent, but English is not my primary language. My english vocabulary is large. Yet, I didn't know potable before this discussion. I did know trunk road, roundabout, shelter and archeological site very well. I would expect drinkable to mean whatever is produced by this tagged feature is safe to drink, and drinking_water to mean somewhere in the tagged area there is a feature that provides access to water that is safe to drink. I also did understand that drinkable, strictly speaking, means that it's _possible_ to drink it, not that it's _safe_. But come on, are we mapping here, or defining physical properties of substances? This isn't OpenPhysicsEngine. Of course, I'm just an anecdote here. But from what I've read of the discussion, it seems my anecdote might represent a larger set of mappers as well. I don't really care which word is used. I generally like specificity, but this seems like an edge case. Due to way OSM is tagged, it should default to most natural possible words in tags. And at least internationally, it seems drinkable is considered more natural. And since it's also a synonym in any normal use (so no specificity is lost), that's the word that should be used for the tag. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] drinkable vs. drinking_water
On 13 July 2012 18:49, Martin Koppenhoefer dieterdre...@gmail.com wrote: interestingly drinkable is mostly used for water that is NOT drinkable: no 1614 68.80% yes 689 29.37% while drinking_water is mostly used for drinking water: yes 296 44.85% no 23034.85% Yes 7811.82% This isn't all that surprising. drinkable is an attribute, drinking_water is a service. Different types of things are used in different tagging contexts. That is also a good argument in opposition to combining those two. IMHO they are not exactly the same but so close that they are probably interchangeable most of the currently tagged objects. But that's not the only angle to consider, it's also relevant that the tagging process makes sense to the tagger. Attributes and services are different things, so it's not just a matter of deciding the better term (e.g. drinkable vs. potable). I'm not saying it's not a good idea to suggest the use of only one tag instead of two that are used to convey the same result (ok there's probably water for me there), But the issue isn't simple. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] drinkable vs. drinking_water
On 13 July 2012 20:30, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/7/13 Ilari Kajaste ilari.kaja...@iki.fi: This isn't all that surprising. drinkable is an attribute, drinking_water is a service. Different types of things are used in different tagging contexts. please note that there are 2 kind of drinking_water: as a value (amenity=drinking_water) which is IMHO the service/feature, and as key, drinking_water=yes/no, which seems to be used as attribute like drinkable. Interesting, good note, thanks. amenity=drinking_water is of course always a service. As for others, I did a bit of digging around, and it seems: drinkable=* is used exclusively as an attribute of a water amenity (mostly =fountain or =drinking_water) drinking_water=* on the other hand is used both 1) as an attribute (e.g. amenity=fountain+driking_water=yes or natural=spring+drinking_water=no) 2) as a further definition for amenity=drinking_water either as 2a) quality attribute (e.g. drinking_water=untreated) or as 2b) type attribute (drinking_water=rainwater_tank or drinking_water=fountain) 3) as an additional service (e.g. amenity=toilets+drinking_water=yes or tourism=alpine_hut+drinking_water=yes or amenity=bench+drinking_water=yes) I didn't know a good tool to make a quantitative look at this, so this is intended only as qualitative difference in cases of how the tags are used in at least some cases. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 2012-06-15 09:07, Colin Smale wrote: The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? To my understanding, the Extended conditions proposal isn't in any way limited to boolean values. In fact, even the examples have numerical values: maxspeed:hgv = 120 maxspeed:hgv:(Sa,Su) = 80 Also opening_hours already implements a complex value-string for multiple values. Using Extended conditions would make it a bit more clear to read, though. For example: opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00; Dec 20-Jan 06 Mo-Fr 12:00-18:00; Dec 20-Jan 06 Sa 12:00-14:00; Jan 01 off could become something like opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00 opening_hours:(Dec 20-Jan 06) = Mo-Fr 12:00-18:00; Sa 12:00-14:00 opening_hours:(Jan 01) = closed or even opening_hours:(Mo-Fr) = 8:00-16:00 opening_hours:(Sa) = 12:00-16:00 opening_hours:(Dec 20-Jan 06 Mo-Fr) = 12:00-18:00 opening_hours:(Dec 20-Jan 06 Sa) = 12:00-14:00 opening_hours:(Jan 01) = closed Though the given example is unusually complex, so it's not a good example of a common case. And as a sidenote I'm not sure OSM database is even the right place for such detailed opening hours, but that's a whole other discussion. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
(Sorry for a possible double-post, this message I sent earlier today (7:52:26 UTC) hasn't yet appeared for some reason.) On 2012-06-15 09:07, Colin Smale wrote: The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? To my understanding, the Extended conditions proposal isn't in any way limited to boolean values. In fact, even the examples have numerical values: maxspeed:hgv = 120 maxspeed:hgv:(Sa,Su) = 80 Also opening_hours already implements a complex value-string for multiple values. Using Extended conditions would make it a bit more clear to read, though. For example: opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00; Dec 20-Jan 06 Mo-Fr 12:00-18:00; Dec 20-Jan 06 Sa 12:00-14:00; Jan 01 off could become something like opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00 opening_hours:(Dec 20-Jan 06) = Mo-Fr 12:00-18:00; Sa 12:00-14:00 opening_hours:(Jan 01) = closed or even opening_hours:(Mo-Fr) = 8:00-16:00 opening_hours:(Sa) = 12:00-16:00 opening_hours:(Dec 20-Jan 06 Mo-Fr) = 12:00-18:00 opening_hours:(Dec 20-Jan 06 Sa) = 12:00-14:00 opening_hours:(Jan 01) = closed Though the given example is unusually complex, so it's not a good example of a common case. And as a sidenote I'm not sure OSM database is even the right place for such detailed opening hours, but that's a whole other discussion. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi fellow mappers! Disclaimer: I'm a relative newbie to OSM, so feel free to take my opinions as such. (I'm not a newbie to usability, data structure definitions or programming though.) On Wed, 13 Jun 2012, Colin Smale wrote: Whatever syntax is used, the *primary* requirement is that it is usable by programs - editors, renderers, routers etc. followed by a secondary requirement that it be understood by humans. If the human aspect was primary, then using a free-text field would be enough as humans are capable of incredible inference - something which normal computers still find challenging. I don't understand your logic here. If the human aspect was the *only* requirement, *then* a free-text field would be enough. Nothing to do with it being a primary requirement, since nobody was saying the tags shouldn't *also* be computer readable - that's why they're kept in a structured format instead of free text. I consider human understandability to be primary. That means, human understandability without any assisting programs (other than maybe direct key/value semantic reference lists for some conformity). I consider computer readability to be secondary. It being secondary does *not* make it *unimportant*. It is still a requirement, just like the human understandability. Why? Mostly becuse OSM seems to be built in that way. Moving away from that looks to me to be a *major* deviation. It's of course still possible it is the right way to go, but it's not how OSM is right now. And it seems to work for OSM.- What I like about the Extended conditions proposal of simply having and-conditions separated by a colon (:) is that it doesn't try to be anything complex that requires you to read any documentation to understand it. You can learn it completely by example, fast. It also matches with the current way of specifying special conditions (subtags) (note that subtags are used for other purposes as well). It really seems to be the OSM way of doing things. The only problem is that it does push data into the keys, but I don't see a good way out of that - bloating the value seems like a bad suggestion as well, and having the As to the conditions vs. subtags differentiation - I don't see there being that big of a difference between them. I do understand the difference, though, but becuse it's often not a clear and intuitive issue, separating conditions from subtags probably shoudn't be done. Introducing a new rather non-intuitive character (?) to mark a difference that isn't in many common context very clear will, in my opinion, cause too much confusion compared to the benefits. Editors can be extended with an expression builder and for advanced users they can be taught to check the syntax before comitting a change. But would this actually happen? Would we get good, understandable expression builders in editors, and would anyone use them? I do doubt it. Having complex laguage that relies on editor support (for most users) doesn't seem like a realistic approach, from what I've seen. But I admit I may be wrong here, since I'm not all that familiar with OSM development history. Next point is that we really shouldn't be spending all our time discussing which delimiter to use and other similar aspects of the physical representation of the data. That's only if we abandon human intuitive understandability. The physical representation does matter if we want humans to type in these conditions. That's why it's being discussed. But if we *do* go into the direction that some tags (these conditions, then probably lanes too) are written as computer-intuitive programmer-understandable instead of humanmapper-intuitive computer-understandable then I would suggest these tags or values could always be prefixed with something (eg. special:, code:, computer:, extended:). That way editors could know to only display them via a special editor, instead of plaintext (unless requested by user). I really would hate to see xml, json or anysuch jumping at a mapper's eyes in some tag/value list - that might have a deterring effect on editing. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
