[Tagging] Tagging for a pack station?
(response to message archived at http://lists.openstreetmap.org/pipermail/tagging/2013-August/014639.html ) I took a look around and likely the closest match, albeit still a far one, would be Trail riding station which is listed among features on the page http://wiki.openstreetmap.org/wiki/Riding . It is telling that though there are ~500 used instances of route=horse, there are no instances for either route=mule, route=donkey or route=pack_animal. So I think that the whole matter of mapping verrry rugged terrain where only pack animals have a reasonable chance of traversing terrain is relatively un-addressed so far. In the case you are looking at, what type of route are you working with? Does it have a designated or preferred animal permissive? Or is it a standard horse route which would be tagged with smoothness=impassable and surface=ground? --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
There are advantages and disadvantages to this. The advantage is, as you point out, you reduce information duplication; there is also the designation of a limited controlled vocabulary which is used as a primary facet. The disadvantage is that the classification of these values as movable is lost from the primary data, meaning that the information relate to all being movable must be sourced from elsewhere. --ceyockey It makes more sense to replace: bridge=movable; bridge:movable=swing bridge=movable; bridge:movable=lift bridge=movable; bridge:movable=bascule bridge=movable; bridge:movable=drawbridge bridge=movable; bridge:movable=transporter with simply bridge=swing bridge=lift bridge=bascule bridge=drawbridge bridge=transporter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Using key:operator to contain building management organization
In particular for business properties, the property or building manager name and contact information is often available on a sign on the building's exterior. In this case I've used the _operator_ key to contain this information. Wondering what your opinion is on the suitability of this. Thanks. --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Landuse vs Place - conversation at talk-key-landuse in wiki
This is a posting on the wiki which I've responded to -- http://wiki.openstreetmap.org/wiki/Talk:Key:landuse#Landuse.3D_-vs-_Place.3D The text of my input, for discussion: My opinion on this is that _place=neighborhood_ implies _landuse=residential_ but not vice versa. In that case, if one has information on a particular area having a name and a boundary which allows one to refer to it as a named place, then neighborhood would be preferred. For instance, a relation of _type=boundary_ and _border_type=subdivision_ I created at http://www.openstreetmap.org/browse/relation/2674522 ; _place=neighborhood_ is on the label node, but it might just as well (maybe better) been put on the relation so that rendering like that via WIWOSM would show a boundary instead of a node. I'm glad to hear people's opposition to or support for this opinion. --Ceyockey (talk) 12:23, 15 February 2013 (UTC) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] business closed for renovation - tagging best practice
Maybe change from _building=yes_ to _building=construction_ and then use _construction=renovation_ ? --ceyockey -Original Message- From: Janko Mihelić Sent: Jan 18, 2013 2:54 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] business closed for renovation - tagging best practice Maybe disused:xxx=yyy could be used for the McDonalds closed for years, and temporary:xxx=yyy could be used for a restaurant closed for a week. The difference is that with temporary:xxx=yyy you also have the xxx=zzz which is the usual longterm value. I think this could be a good system. Janko ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Adopt-a-highway representation in OSM
There is a thread of discussion on the Talk-us board about how and whether to represent Adopt-a-highway features. Seehttp://lists.openstreetmap.org/pipermail/talk-us/2013-January/010086.htmlas the top of the thread. It was suggested that this come over to the tagging board for further discussion. --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Adopt-a-highway representation in OSM (this time in plain text)
I should have also pointed at the revision to the original suggestion which I wrote after comments were provided at talk-us -- see http://lists.openstreetmap.org/pipermail/talk-us/2013-January/010187.html . This doesn't use amenity. --ceyockey -Original Message- From: Chris66 chris66...@gmx.de Sent: Jan 12, 2013 11:34 AM To: tagging@openstreetmap.org Subject: Re: [Tagging] Adopt-a-highway representation in OSM (this time in plain text) Am 12.01.2013 17:21, ceyockey wrote: There is a thread of discussion on the Talk-us board about how and whether to represent Adopt-a-highway features. See http://lists.openstreetmap.org/pipermail/talk-us/2013-January/010086.html as the top of the thread. It was suggested that this come over to the tagging board for further discussion. Hi, I'm not lucky with the amenity-Tag. Don't think this feature is a amenity. Chris ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Multiple Purposes for Buildings - forum for discussion of indoor mapping
Consider posting at or joininghttp://forum.openstreetmap.org/viewforum.php?id=67, which is dedicated to 'indoor mapping'. I've noted this discussion thread athttp://wiki.openstreetmap.org/wiki/Talk:Indoor_Mapping. --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] GNC (General Nutrition Centers) - variety of shop tag values
I wanted to tag a GNC franchise outlet in the United States and wasn't quite
sure what value to use for the shop key. I find that I'm not alone. Using
OpenLinkMap, I identified most of the current GNC outlets mapped in the US and
recorded the key:shop values ... all of the variants appeared once; if more
than once, the number is in parentheses:
shop=vitamin
shop=vitamins
shop=nutrition
shop=Health
shop=health
shop=herbalist (3)
shop=yes (2)
shop=pharmacy
shop=doityourself
(no shop tag) (2)
Depending how you look at it, this is either a healthy reflection of the
ability to tag anything with anything, or an indicator of the current anarchic
state of tagging :-) (the number found is also an indicator of the % coverage
for chain shops in general ... there are 6000 GNC stores in the United States)
Be that as it may, and allowing for variation from store to store, I'm
wondering if it might not be useful to identify a base tag value for shop
chains, allowing for additional values to be added if a particular location
varies from the chain template. Looking at the wikipedia article, GNC
(store), the informative categories used are health food stores and
nutrition. Looking in TagInfo shows that the value health_food is
available for key:shop at about rank 170 with 57 uses; nutrition shows up as
three items in TagInfo, nutrition (20), nutrition_supplements (3) and
nutritional_supplements (1).
If one were to make a suggestion for a base tag for the GNC franchise, one
could, thus, go by the Wikipedia categorization and put it into both
health_food and nutrition as {{tag|shop|health_food;nutrition}}. This is
what I'll do on the shop I'm putting in now, but I wanted to bring this out to
stimulate conversation on whether or not a guideline of consistent baseline
tagging for stores in a chain might be beneficial to the OSM dataset or not.
The Wiki could be used to store the outcomes of discussions here.
--ceyockey
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Names on relations and not component ways
...why do you duplicate the tag waterway=river on every way Because the relation can contain more than simply the waterway. For instance, one could add the riverbank, islets, and slips if one were so inclined. By letting each component way retain an identity of what it is, the relation grouping takes on the purpose of telling what it's called, it being the variety of component types which make up the thing called Tappahanna Ditch. I just haven't added any of the extra things (chief being the riverbank) to the relation (and likely never will). --ceyockey -Original Message- From: Georg Feddern o...@bavarianmallet.de Sent: Jan 6, 2013 11:30 AM To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Names on relations and not component ways Hello, Am 04.01.2013 14:43, schrieb dies38...@mypacks.net: I recently created a waterway where I put the name of the waterway on the relation but not on the component ways which are grouped by the relation. To me, not duplicating data would seem to be the better overall practice, and duplication of well, it's one acceptable perception to enter the data into a 'relational' database - opposite to the 'keep it simple on every way' perception. But why do you duplicate the tag waterway=river on every way then ...? Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Brand vs. Franchise
In an earlier message it was suggested that I use key:brand for a store in a chain. An alternative is to use key:franchise. Key:Brand is (much) more widely used in terms of instances. Key:franchise implies a conservation of business model by franchisees and goes along with a shared brand; sharing a brand does not imply that there is a franchise relationship. My thinking is that key:franchise should be discouraged in favor of key:brand where the intention is to show an observable relationship between a single store and a chain evidenced only by names. In this sense, key:franchise is like key:landuse while key:brand is like key:landcover mdash; the former implies a knowledge of they why and how, while the latter implies knowledge of what. Key:franchise could be used in addition if there is documentation to support it. If there is agreement on this, I'd suggest working to clean and close http://wiki.openstreetmap.org/wiki/Key:franchise so that a clear demarcation between use can be documented. --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Names on relations and not component ways
Thanks for the several comments from people. I decided to remove the relation and name each component way individually. I referred to this conversation in the changeset meta-data (source and source_ref). Regards --ceyockey. -Original Message- From: Werner Hoch werner...@gmx.de Sent: Jan 6, 2013 4:54 PM To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Names on relations and not component ways Hi ceyockey, Am Freitag, den 04.01.2013, 08:43 -0500 schrieb dies38...@mypacks.net: I recently created a waterway where I put the name of the waterway on the relation but not on the component ways which are grouped by the relation. This results in the name of the waterway not appearing in the standard Map view. AFAIR there's currently no relation type that inherits it's tags to the member ways, so that the name tags are rendered on the map. Road routes do not inherit there ref tags to the highways, associatedStreets do not inherit there street name to the highway segments. Those relations use duplicate tags, too. There's only one rarely used concept of tag inheritance: http://wiki.openstreetmap.org/wiki/Relation:multilinestring that is AFAIR not supported by the renderers. I am wondering what current best practice is. Should name be applied to both component ways and relation, or is application of name to relation sufficient. For waterways, adding one name to ways and all names to the relation is at least useful. Longer waterways (rivers) sometimes do not have the same name over the complete length, because they flow across different countries. e.g. The Danube river: http://www.openstreetmap.org/browse/relation/89652 To me, not duplicating data would seem to be the better overall practice, and duplication of name on relation and component ways would seem to be a case of tagging-for-the-renderer. IMHO, redundancy is not always a bad thing. Just do not add too much. (p.s. the waterway in question = http://www.openstreetmap.org/browse/relation/2676618) For that short waterway it wouldn't create a waterway relation [1], as the benefits of the extra relation are low. * no international names required * no wikipedia reference * the waterway has the same name on all segments. * no gnis reference tag, ... [1] http://wiki.openstreetmap.org/wiki/Relation:waterway Regards Werner (werner2101) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Source tag - deprecated for use on objects?
I posted the original question/comment and have been testing a switch over to
providing source information _only_ on changesets. I posted a followup message
which related the source-on-changeset matter to provenance in RDF data .. I
think that the source-on-changeset is as valid as and more conservative with
respect to data duplication than the source-on-object solution. I won't go
into detail about RDF quads and quints versus linked data-based provenance
because it makes my head hurt to just think about it (I'm early in the learning
curve), but the source-on-changeset is a more elegant solution than the
source-on-object and what we need to do is to revise the Potlatch and JOSM
interfaces in a way to take advantage of this elegance and expose the source
data to editors in a similar manner regardless of whether it is on the object
or the changeset.
From an editing point of view, leaving source to be reported on changeset
works to significantly reduce the amount of tag-value content you have to deal
with while adding content. That is a very good thing.
In closing -- I'm a convert to source, source_ref, source:date and other
variations being added to the changeset ... at least given my current editing
behavior.
--ceyockey
-Original Message-
From: Ilari Kajaste ilari.kaja...@iki.fi
Sent: Jan 6, 2013 6:06 PM
To: Tag discussion, strategy and related tools tagging@openstreetmap.org
Subject: 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 mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Names on relations and not component ways
Thanks -- the rationale embodied in the sentence quoted from Toby Murray below was what drove me to use a relation: It allows one real world object to be represented by one object in OSM and reduces duplication of tags on component ways. --ceyockey -Original Message- From: Toby Murray toby.mur...@gmail.com Sent: Jan 5, 2013 1:17 PM To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Names on relations and not component ways Large river tagging is kind of a mess so I'm not quite sure where I stand on this. But we also use relations to map lakes that are too big to be mapped with a single way because of the 2,000 node limit. It seems like rivers are in a similar situation and the use of a relation does not seem completely out of place. It allows one real world object to be represented by one object in OSM and reduces duplication of tags on component ways. Toby ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Names on relations and not component ways
Hello -- I recently created a waterway where I put the name of the waterway on the relation but not on the component ways which are grouped by the relation. This results in the name of the waterway not appearing in the standard Map view. I am wondering what current best practice is. Should name be applied to both component ways and relation, or is application of name to relation sufficient. To me, not duplicating data would seem to be the better overall practice, and duplication of name on relation and component ways would seem to be a case of tagging-for-the-renderer. Thanks for your input. --ceyockey (p.s. the waterway in question = http://www.openstreetmap.org/browse/relation/2676618 ) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Names on relations and not component ways
The waterway segments I collected into the relation are exactly analogous to roadway segments collected into a route relation. I do not think that the relation I created constitutes a category, really. --ceyockey -Original Message- From: Chris66 chris66...@gmx.de Sent: Jan 4, 2013 4:38 PM To: tagging@openstreetmap.org Subject: Re: [Tagging] Names on relations and not component ways Am 04.01.2013 14:43, schrieb ceyockey: Hello -- I recently created a waterway where I put the name of the waterway on the relation but not on the component ways which are grouped by the relation. This results in the name of the waterway not appearing in the standard Map view. I am wondering what current best practice is. Should name be applied to both component ways and relation, or is application of name to relation sufficient. To me, not duplicating data would seem to be the better overall practice, and duplication of name on relation and component ways would seem to be a case of tagging-for-the-renderer. Thanks for your input. (p.s. the waterway in question = http://www.openstreetmap.org/browse/relation/2676618) In my opinion the relation is unnecessary. See also: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Chris ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Source tag - deprecated for use on objects?
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. This is not reflected in anything I can find on the wiki, and I've done an incomplete search of the subject fields on this forum to see if this has been discussed. Could you please clarify this for me? Should I a) not be adding {{key|source}} to objects and b) should I be adding content in such a way that a single source tag on the changeset is valid for all content in that changeset (this has major implications for my editing behavior). Thanks. --ceyockey
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Source tag - deprecated for use on objects?
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. This is
not reflected in anything I can find on the wiki, and I've done an incomplete
search of the subject fields on this forum to see if this has been discussed.
Could you please clarify this for me? Should I a) not be adding {{key|source}}
to objects and b) should I be adding content in such a way that a single source
tag on the changeset is valid for all content in that changeset (this has major
implications for my editing behavior). Thanks. --ceyockey
P.S. apologies -- I sent an html format email prior to this and it got scrubbed
by the list management software.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
[Tagging] New tag proposal Amenity=meditation centre
(reply to message at http://lists.openstreetmap.org/pipermail/tagging/2012-September/011278.html ) I am wondering whether this tag might be used for something like Christian Science Reading Room locations. Though not really a 'meditation center', such a location aims to provide an alternative to a formal church for people of a particular faith to gather. --ceyockey Christian Science Reading Room on Wikipedia -- http://en.wikipedia.org/wiki/Christian_Science_Reading_Room ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] access=no (was Amenity swimming_pool (was Amenity parking))
There was some mention in this thread of the some lack of utility of access=no as a tag-value pair as someone usually has access to somewhere, it is just impeded by rules or physical barriers; I do agree with this in general. If we move to the inclusion of a historical layer, then access=no could, in fact, be a default parameter for historical features as they are truly not accessible due to a time barrier. --ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tag desired for maintenance - comment on utility
This relates to the thread Tag desired for maintenance which begins at http://lists.openstreetmap.org/pipermail/tagging/2011-November/008887.html . My gut feeling is that it is more beneficial to bring civic services into the fold in using OSM as a micro-mapping resource than it is to reflect maintenance status in the map itself. As a for instance, I'll relate what I have tried to do several times for street light outages in my neighborhood. There is an online form for reporting street light outages in my area. The positional information requested is along the lines of intersection / cross-street. What I have provided with my reports is a cross-reference via URL to an OSM object which is the street light which required maintenance. I have no idea whether the maintenance organization actually used this info or not. What I would like to see rather than reflection of maintenance status in OSM would be a true integration of open311 or other legacy systems with OSM so that the involved object (be it a streetlight or a hydrant, a footway or a bridge) could be unambiguously geo-located via an OSM reference. One could include maintenance status in a tag on the object, but the key use case for OSM data would remain unambiguous geo-location. The main problem I have with transients in OSM data is that their updating to reflect current state (e.g. change from impaired to repaired) is dependent upon a volunteer observation and a volunteer OSM data revision. In my opinion, the availability of volunteer resource is not consistent with the requirements for real-time condition monitoring required for maintaining true values for the proposed maintenance tag. Regards - OSM user ceyockey ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Why addr:state rather than is_in:state? (response to 2010-12-26 05:29:46)
(from ceyockey) I am of the opinion that addr:state should only be used in the context of an address, not as a standalone synonym for is_in:state, meaning that I support the use of is_in:state for routes. (http://wiki.openstreetmap.org/wiki/User:Ceyockey) ==ORIGINAL BELOW== From: Nathan Edgars II Subject: Why addr:state rather than is_in:state? Newsgroups: gmane.comp.gis.openstreetmap.tagging, gmane.comp.gis.openstreetmap.region.us Date: 2010-12-26 05:29:46 GMT (2 days, 17 hours and 26 minutes ago) Many route relations use addr:state to describe what state the route is in. Should a tag intended for addresses be used this way, or is is_in:state a better tag to use? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Deprecated features - highway=disused
I came across http://wiki.openstreetmap.org/wiki/Proposed_features/Disused_road today. I applied the proposal page template, indicating that the proposal had been obsoleted, as noted in the commentary on the page. Looking at the tag info for highway (http://taginfo.openstreetmap.de/keys/highway), I see that there are presently 88 instances of highway=disused. Would you support addition of highway=discussed to http://wiki.openstreetmap.org/wiki/Deprecated_features as: * Date: (date of agreement here) * Old Key/Value: highway=disused * Suggested Replacement: highway=* disused=yes access=yes (no implied) * Reason: creation of general disused key The main problem I see with this proposal is the indication at key:disused that the use of the key implies access=no, which is not necessarily true in the case of a highway which is disused. Could this be circumvented by the inclusion of the 'access=yes' recommendation in the suggested replacement? Thanks for considering this. --ceyockey (http://wiki.openstreetmap.org/wiki/User:Ceyockey) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
