Re: [Tagging] man_made=works
Once you're out of a comfort zone, you're lost - there are no easy hints or rules how to tag some similar or more general things. You just have to create completely fresh tags and hope other will agree. That is true for seasoned mappers, but even more true for casual ones. that's true, the tagging schema is open, but guidelines might be welcome to extend it. Also look at the reception_desk classification problem. Some want to classify it as amenity, others as a tourism feature. That just depends on your needs. There isn't always a classification that works for everyone. But we're just mentally caged in a *=reception_desk schema, so you still have to be sure what class is this object. In my view you could tag it only reception_desk=yes if you don't know or care for classification, but you're still able to make it reception_desk=tourism for example, if that's what you're sure about. I envision classification as a metadata level - we can still have default one, but outside the GIS database, which would make it easier to extend it if needed (the more objects, the stronger need to have something extendable and with more layers). Others can still use our classification or make their own. Taking the categories outside the database and letting mappers tag only what they are sure is a win-win situation IMO. I'll agree that introducing the reception_desk key was/is problematic because of the choice of the top level tag. The need to choose top-level tag for it is the problem itself. What's a top level key ? Suppose you drop shop. Then you get bakery=yes. Is bakery now a top level key ? Is everything acceptable as top level in this new schema ? Won't we have discussions on what is acceptable as top level then ? On the other hand I do not see why we couldn't tag some of them as amenity and others as tourism and have both documented. It's pretty easy for data consumers to support both. And what about presets? Will there be two of them? Why not ? OTOH when there is only 1 preset, people are still free to use a different top level key (and document it), or even make their own preset. Maybe we should demand that each tagging proposal includes a preset for JOSM and iD, it might also increase acceptance and usage of new tags. And what about another kind of reception desk we haven't heard of yet? It's easy to believe we already have all the tools for mapping the world just because we know our city/town/village/country in general (or even some other countries to some extent), but this may not be enough in the future. I agree, but you see only the half of the issue. Of course we know just a compact version sometimes (like amenity=reception_desk or tourism=reception_desk), but we have no tools to chop it to say it's really reception_desk=yes + amenity=yes or reception_desk=yes + tourism=yes. Why do you need to specify amenity = yes or tourism = yes ? What do I learn from that ? Is this for the case that there are 2 reception desks on a property (thinking about a campsite here), where one is used by the tourist and the other for deliveries ? I still haven't figured out for myself whether top level keys bring a lot of benefits. I suppose they do for building or shop (see e.g. SK53 latest diary entry on shop statistics, which won't be possible with a top-level shop tag). But does it help for things amenity, leisure or tourism, which are really collections of totally different things ? Would they be better off without those top level tags ? regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=works
2015-06-01 11:51 GMT+02:00 Daniel Koć daniel@koć.pl: You _have_ to decide whether it's a shop=travel_agency or office=travel_agent. no, you don't have to, you can also use both tags if you think they should apply both. Also look at the reception_desk classification problem. Some want to classify it as amenity, others as a tourism feature. That just depends on your needs. There isn't always a classification that works for everyone. But we're just mentally caged in a *=reception_desk schema, so you still have to be sure what class is this object. In my view you could tag it only reception_desk=yes if you don't know or care for classification, but you're still able to make it reception_desk=tourism for example, if that's what you're sure about. having few keys and many values has a certain advantage in certain database systems, turning this the other way round will not let you gain much but will have negative implications for those systems. Plus you loose the generic classes that might be useful for finding tags or for filtering (e.g. all shops in this area is harder or impossible if the scheme goes: grocery=yes / shop). And what about presets? Will there be two of them? If we want to have consistent tagging and details, simple presets the way we have them now will not be sufficient. We should better have a guided scenario (aka wizard) that asks the mapper some questions and in the end proposes the tags to set or states that there aren't yet tags for this kind of thing. This would also decourage people from using similar but not pertinent tags. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=works
W dniu 01.06.2015 7:15, Marc Gemis napisał(a): On Mon, Jun 1, 2015 at 12:48 AM, Warin 61sundow...@gmail.com wrote: The mixed ones in particular are hard to mentally recall, organise. Do you think a tagging schema with several different sub tags is easier ? Just use the presets in case you don't remember. Sub tags may not be the answer (especially if the mixing is going on a level above the primary tag), but the presets won't help you too in such cases, because they're made only for easy finding typical objects. Once you're out of a comfort zone, you're lost - there are no easy hints or rules how to tag some similar or more general things. You just have to create completely fresh tags and hope other will agree. That is true for seasoned mappers, but even more true for casual ones. Where/ how do you want to organise ? I usually use search, so I don't encounter the classification problem often. And isn't the classification problem a rather personal problem? E.g. some apps want to group pubs that serve, restaurants, fast food etc. in one category. I think OsmAnd does. Every data consumer is of course free to use a different grouping/classification from the one that is in the raw data. Sure, but the OSM itself tries to make classification a hard requirement, because it's a first class citizen in our current schema. You _have_ to decide whether it's a shop=travel_agency or office=travel_agent. Sure, the presets make it easier here (just one true k=v), but what if Wiki pages are unsure? That's still a lottery then - you just buy a ticket somebody else took the numbers for you. Also look at the reception_desk classification problem. Some want to classify it as amenity, others as a tourism feature. That just depends on your needs. There isn't always a classification that works for everyone. But we're just mentally caged in a *=reception_desk schema, so you still have to be sure what class is this object. In my view you could tag it only reception_desk=yes if you don't know or care for classification, but you're still able to make it reception_desk=tourism for example, if that's what you're sure about. I envision classification as a metadata level - we can still have default one, but outside the GIS database, which would make it easier to extend it if needed (the more objects, the stronger need to have something extendable and with more layers). Others can still use our classification or make their own. Taking the categories outside the database and letting mappers tag only what they are sure is a win-win situation IMO. Reorganisation should bring big benefits, placing e.g. fountain under tourism does not bring huge benefits IMHO. I agree, just changing the categories for objects is not gonna work. I'll agree that introducing the reception_desk key was/is problematic because of the choice of the top level tag. The need to choose top-level tag for it is the problem itself. On the other hand I do not see why we couldn't tag some of them as amenity and others as tourism and have both documented. It's pretty easy for data consumers to support both. And what about presets? Will there be two of them? And what about another kind of reception desk we haven't heard of yet? It's easy to believe we already have all the tools for mapping the world just because we know our city/town/village/country in general (or even some other countries to some extent), but this may not be enough in the future. I think we should concentrate on ground truth (this is a reception desk) and make classification based on it (and other hints, if available), not the other way around. Take a look at e.g. historic places. They support all kind of combination for the same things (building=farm, historic=yes or just historic=farm). They process the data before putting it on the map, so those things appear the same for the users of that map. I agree, but you see only the half of the issue. Of course we know just a compact version sometimes (like amenity=reception_desk or tourism=reception_desk), but we have no tools to chop it to say it's really reception_desk=yes + amenity=yes or reception_desk=yes + tourism=yes. That's the key problem here: we can always glue things together to make them more complex, but we have no system to extract more general properties if we don't know details or we want to tag something similar but with other details! As I understood the power_sockets problem is that some want to generalize the power_socket concept. Do we always have to try to find the most general concept and add X number of subtags to say what we really want to say ? Or can we sometimes just live with the specialty object (charging place for cars). We can definitely live with specialty objects! Wikipedia have already showed that human knowledge is not easy to categorize in a hard way, because we tend to see some important things as different. So let's not drop the typical
Re: [Tagging] man_made=works
W dniu 01.06.2015 14:18, Marc Gemis napisał(a): The need to choose top-level tag for it is the problem itself. What's a top level key ? Suppose you drop shop. Then you get bakery=yes. Is bakery now a top level key ? Is everything acceptable as top level in this new schema ? Won't we have discussions on what is acceptable as top level then ? Good question, indeed! In theory we have nothing like top level keys - highway=service + area=yes may mean service road, that has a known area border, but we may also read it like area=yes + highway=service (the area, which has a property of being service road). So far, so good, but in practice we strongly depend on such namespaces like building, highway, shop, craft, amenity - and try to stick with them as closely as possible. Not even such notable examples as public_transport or Healthcare 2.0 really took off. It looks like we need a set of useful categories and don't like to loose the known, legacy set. But I'm sure this set have to be better and not that rigid. And I think it's possible to fulfill all those needs. If we have bakery=shop (aka shop=bakery today), we can safely assume it belongs to shop category. And if we have more or less proper, dynamic category tree outside (in metadata), we can assume that bakery=yes and all the other values except no are also shop in fact. Nothing changes - the category is here to be used. We don't really drop anything, we just move it somewhere else. Now, you can accept it as top level or not, at your discretion. But you will also have subcategory food_and_drink_shops, where the bakery is really located - maybe it's more useful as a top level category for you? We can treat old categories as a legacy - they will stay with us, but will not be the hard requirement (in practice) anymore. You will automatically know that health_specialty:dentistry=yes is amenity, because it's categorized in health_amenities subcategory, so you loose nothing; but at the same time you don't have to abuse amenity=* namespace and you can choose health as your top level category. Maybe we should demand that each tagging proposal includes a preset for JOSM and iD, it might also increase acceptance and usage of new tags. I would be very happy with having common set of presets! The external category tree is for nicely extending our objects base as they grow (and they really do!), the presets are for easy using already defined and agreed upon values. I hope wiki, map editors (I mean software) and default rendering will make OSM more of a collaborative environment than it is today. We could start with synchronizing JOSM and iD presets, probably. Why do you need to specify amenity = yes or tourism = yes ? What do I learn from that ? Is this for the case that there are 2 reception desks on a property (thinking about a campsite here), where one is used by the tourist and the other for deliveries ? You should not specify anything, unless you want to indicate that you know it for sure - just like with plain old building=*. If you don't know or you're unable to tell, better make it only reception_desk=yes. This way you won't silently spoil the data with wild guessing. It's always better if you know exactly and collect as many informations as possible, sure. But it's also better to know when something is uncertain or just more general, than insist on adding details at all cost - the cost being cutting some information, sneaking the entropy into database (ever heard of Procrustean bed?) or losing the input at all, as the mapper is unable to tell and abstains from adding anything. We've just learned to not take these hidden costs into account, because - well - they're hidden and we don't think a better categorization is possible (or needed). I still haven't figured out for myself whether top level keys bring a lot of benefits. I suppose they do for building or shop (see e.g. SK53 latest diary entry on shop statistics, which won't be possible with a top-level shop tag). But does it help for things amenity, leisure or tourism, which are really collections of totally different things ? Would they be better off without those top level tags ? I know that some of them are better, and some other are worse. Building, highway, area, water, shop, public_transport are nice. Amenity, man_made, landuse, natural or leisure are not that clear. But they don't need to be really top-level. Building is just useful entity, however we could probably argue that it's kind of area and man made at the same time. So let's put it under both categories then. It's not top-level now (the only really top-level might be object), but what's the problem? We can still use it as a basic structure for our needs, as we do it now! -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ Tagging mailing list Tagging@openstreetmap.org
Re: [Tagging] man_made=works
W dniu 01.06.2015 13:51, Martin Koppenhoefer napisał(a): 2015-06-01 11:51 GMT+02:00 Daniel Koć daniel@koć.pl: You _have_ to decide whether it's a shop=travel_agency or office=travel_agent. no, you don't have to, you can also use both tags if you think they should apply both. But it's not just a simple case of a mapper not knowing what category key should be used. It's that we as a project don't know how to properly categorize this kind of object. We could fix it that way for every not-so-clear-type object, but how much better is this double (or maybe more) tagging than one object belonging to two (or more) categories? From the ground truth perspective it is just a travel agency, not two different entities. having few keys and many values has a certain advantage in certain database systems, turning this the other way round will not let you gain much but will have negative implications for those systems. Plus you loose the generic classes that might be useful for finding tags or for filtering (e.g. all shops in this area is harder or impossible if the scheme goes: grocery=yes / shop). I don't want to loose any of the current classes! They will be always needed, at least for legacy migration purposes. I just want to make them broader, more flexible context for the objects. If we have more detailed tree of objects, we can still filter all the objects belonging to this category and subcategories. If you're really sure the grocery should always be taken as a shop, even if not described as grocery=shop (or grocery=yes+shop=yes) by the mapper, you can make any value (except grocery=no probably) to mean it's a shop. But what if you were wrong and there are for examples some places with free groceries to take? You're still sure the grocery=shop is a shop, but you may start using grocery=free as something else - and maybe treat all the other grocery=* values also as something different or just drop default shop category just in case, and wait for the mappers to make sure and tag it accordingly. That's simple rule, I guess: if the mapper is sure that grocery=shop, you can trust her. But if she's not and refuses to decide, you can still enforce the type, just like currently - except it's explicitly known that your choice then, not the mapper's! As for now, we're silently enforcing the mapper to decide even if she's not sure; with categories not being compulsive, we have less hidden errors in the data itself, and all the responsibility for dealing with generalities and ambiguities is on the proper category tree and clients using it. But with more responsibility comes more flexibility. =} If we want to have consistent tagging and details, simple presets the way we have them now will not be sufficient. We should better have a guided scenario (aka wizard) that asks the mapper some questions and in the end proposes the tags to set or states that there aren't yet tags for this kind of thing. This would also decourage people from using similar but not pertinent tags. Great idea! This could also be a perfect loopback for us to know what people are trying to achieve, so we know what tagging scheme is missing. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=works
Am 01.06.2015 um 17:46 schrieb Daniel Koć daniel@koć.pl: In theory we have nothing like top level keys - highway=service + area=yes may mean service road, that has a known area border, no, that would be tagged area:highway=service but we may also read it like area=yes + highway=service (the area, which has a property of being service road not even, it is an area without directional traffic cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=works
W dniu 01.06.2015 20:51, Martin Koppenhoefer napisał(a): no, that would be tagged area:highway=service not even, it is an area without directional traffic I would say that the example is really the least important part here and you are nitpicking. =} The same could be true with amenity=school+building=yes or building=yes+amenity=school (which one is really top here and which is just a property of it; or does it really matter?) and anything else. What is important is that technically we got flat tagging scheme (not nested, nor even ordered one, probably with exception of relations), so it's up to us to say what is top level. Or if we really wouldn't be able to act efficiently without such concept at all - which I have showed is not true in general. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Reception Desk.
Hi, Voting for the mark 2 version of Reception Desk is now open. Link https://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk A Reception Desk provides a place where people (visitors, patients, or clients) arrive to be greeted, any information recorded, the relevant person is contacted and the visitor/s, patient/s, or client/s sent on to the relevant person/place. It is particularly useful to know the location of the reception desk when it is located away from the typical place (near a front entry) or where there is only one amongst a number of large buildings. First seen as a suggested extended tag for camp sites http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site%7C, thought to have a wider application to offices, hotels, hospitals and educational features. The amenity key is chosen so it can be used for both tourism and business situations. Thanks for your participation. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
