Re: [Tagging] About the diaper key
As my small contribution, switched to changing_table in a baby care proposal page~ https://wiki.openstreetmap.org/wiki/Proposed_features/babycare 2019年6月17日(月) 5:44 Rory : > Hi, > > On Wed, 12 Jun 2019 16:14:59 +0200, Valor Naram wrote: > > the proposal at > > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table has > > been accepted now and I can start with the post-vote process and > > creating a wiki page. The property Key:changing_table success the > > Key:diaper for now but we or at least I have to deal with the question > > "What's going on with the diaper key". The answer seems clear: > > Key:diaper is now superseded by Key:changing_table. While it's the part > > you CAN definetly answer with ease. The second part properly not. "What > > do we do with the POIs having the Key:diaper?" > > > > I am very excited about hearing your ideas since some of you noted that > > just replacing the diaper key and its values with the key and the values > > of the new key can be problematic. > > I suggest finding data consumers (people/apps/sites/software which uses > the existing `diaper` tag), and talking to them about supporting the new > `changing_table` tag. Likewise talk to data contributors (editing > software) and talk them into supporting your new scheme. > > I really don't think a mechanical edit to change all is a good idea. You > can't rely on all data consumers to read all lists & wiki pages, and you > risk a data consumer re-adding the `diaper` tag. > > If no-one's using the `diaper` tag, then why not make or encourage data > consumers to support it? > > Rory > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Crossroad names
Why don't use our old "relation = tarffic_lights"? (or junction?) http://wiki.openstreetmap.org/wiki/Relations/Proposed/Traffic_Lights (yes, it need more advanced!) I would like to against write them as area. Relation feature essentially means, "group up some objects to represent as a feature". So I think it could suite for our traffic_signal & junction naming, routing. (relation could express "label" membership) 2013/3/29 Pieren > On Thu, Mar 28, 2013 at 2:22 PM, Janko Mihelić wrote: > > > I saw this proposal before and I liked it. Now I like it even more > because > > it solves the junction name problem. > > As area, only used 3 times by 2 different users in one year (date of > the proposal): > > 2 by the proposal writer "imagic": > http://www.openstreetmap.org/browse/way/210448306 > http://www.openstreetmap.org/browse/way/202280167 > > 1 by "Soldier Boy": > http://www.openstreetmap.org/browse/way/190569949 > > Another one is a mistake (roundabout): > http://www.openstreetmap.org/browse/way/43114115 > > Not something I would call "a success". > > But 1132 relations of type "junction": > http://taginfo.openstreetmap.org/tags/type=junction > http://taginfo.openstreetmap.org/relations/junction#overview > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Junctions > > Pieren > > ___ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC: Japanese address, place revise (Block system address)
Hi, list I'm working on expressing Japanese address structure. Also, revising "place" structure. We JP had collected samples, and made a structure from them. Please tell us your comments. (I'm preparing wiki page editing) https://docs.google.com/spreadsheet/ccc?key=0ApY7X6fw8sqxdDNjY1FBeG00TlRZSFoxU2xwOHVCb0E#gid=1 * Block addressing System In general "Block Address System" structure, it could be compatible between "addr:street" and "addr:blocknumber". It is simple :) * JP Situation JP address system are very messy. Since it is a mixture of general "Block Number System" and "from Old Cadestra System". Some local governments treats Cadestra as Address representation. So, many many exceptions are there. But IMHO, the whole structural order is simple. * Key proposal addr:blocknumber subprovince (as "place" structure) Using "quarter" (as "place" and "addr:quarter" structure) * Challanges 1. Using key "quarter" I understand that "place=quarter" is under proposal, and non-recommended key. Please tell me if there are some another choice. http://wiki.openstreetmap.org/wiki/Proposed_features/place%3Dquarter In Japan, neighbourhood is divided "upper" and "lower". So I use "quarter" as represent "Upper Neighbourhood". Should we use another word to represent "Upper Neighbourhood"? (e.g. "neighbourhood" and "subneighbourhood" come to mind) "Upper" and "Lower" are very separated ones, so they are difficult to merge as one "neighbourhood", I think. 2. subprovince We would like to use it as structural order. 3. addr:housenumber may contain "NULL" In some case, "addr:housenumber" contain "NULL". (in fact, it seems as 1 or 1-1. But numbers are vanished, even in public description) Is it permissive? * reference pages http://wiki.openstreetmap.org/wiki/Key:place http://wiki.openstreetmap.org/wiki/Key:addr Regards. -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Japanese address, place revise (Block system address)
Thank you for reply. Here is a most simple example. If we need more complex ones, I'll make them. * City level Whole Chiba "city" Chiba city has 6 "suburb"s. See "subarea" member of relation, for details. http://www.openstreetmap.org/browse/relation/2679956 * Suburb level This is one of the suburb. Named "Chuo-ku" (means "Center ward". 中央区) "Chuo-ku" has 7 "Upper Neighbourhood"s. http://www.openstreetmap.org/browse/relation/2679950 * Upper Neighbourhood This is one of the Upper Neighbourhood. Named "Matsunami" area. (松波) "Matsunami" area has 4 "Lower Neighbourhood"s. http://www.openstreetmap.org/browse/relation/2905610 * Lower Neighbourhood This is one of the Lower Neighbourhood. Named "1 Chome" area(means "1st area", 一丁目 or 1丁目). "1 Chome" is divided into 19 blocks. http://www.openstreetmap.org/browse/relation/2905589 * Block address "1 Chome" of "Matunami" has 19 blocks. The polygon divided by roads are called "block". Those are well not mapped on OSM, here is a sample image. http://wiki.openstreetmap.org/wiki/File:Japanese_address_blocknumber.png * Housenumber address e.g. 12th block has 7 "house"s. Each house has it's own "housenumber". (In some case, may contain branch, gap, or missing numbers.) http://wiki.openstreetmap.org/wiki/File:Japanese_address_housenumber.png * Same area on other maps. ** Japan Government map http://portal.cyberjapan.jp/site/mapuse4/index.html?lat=35.61716&lon=140.110089&z=17&did=DJBMM ** Yahoo! Japan Maps http://yahoo.jp/Ihjmkg And then, I'm afraid of my choise of the words to place tag namimg. May be some conflict will occur on use of "quarter" with other country. Regards. 2013/9/18 Serge Wroclawski > Perhaps this is one of those "a picture is worth a thousand words" > type situations. > > I know that the Japanese system for addressing is quite different than > the system we think of in the West. > > Can you perhaps show us what a map of addresses looks like in another > map, and then show an OSM example of what your proposal would look > like? > > Obviously the most important community that this needs to make sense > to are local (Japanese) mappers, but it might be nice if the rest of > us understood as well. > > - Serge > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dress Code proposal
Interesting idea, i think. It could be applied to permanent POI, such a restaurant or so. It could be a bit classified like "grade" tag of highway=track? dress_code = formal : full suits, tie, traditional-wear dress_code = "something between here": I don't have enough word to distinguish that... dress_code = casual : jeans, denims, T-shirts. default. dress_code = nudist : only full nude is permissive :P > I think a better approach is to have a tag that links to the venue's web site, which we already have tags defined for. +1 2013/10/24 John F. Eldredge > Frederik Ramm wrote: >> >> Hi, >> >> On 10/23/2013 09:50 AM, Tom Morris wrote: >> >>> I have just put up a draft proposal for tagging venues with dress code. >> >> >> Are you sure that this isn't taking things a bit too far for a >> geographic database? Dresscodes will often apply to events, not >> locations; events can move between locations. It doesn't seem to make a >> lot of sense to me! >> >> Bye >> Frederik >> >> > I think a better approach is to have a tag that links to the venue's web > site, which we already have tags defined for. > > -- > John F. Eldredge -- j...@jfeldredge.com > "Darkness cannot drive out darkness: only light can do that. > Hate cannot drive out hate: only love can do that." > Dr. Martin Luther King, Jr. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag babycare?
Hi list, I'm a bit wondering how to tag following babycare amenities. Possibly those are additional feature for childcare 2.0 schema, but usable with other POIs. (e.g. w/ amenity=cafe, toilet, or so.) http://wiki.openstreetmap.org/wiki/Proposed_features/childcare2.0 * where to replace baby's diaper. ** according to Taginfo, "diaper=[yes|no|room]" ? * where to access with stroller/pushchair ** according to Taginfo, "stroller=[yes|no|limited]"? ** very similar schema as "wheelchair=*". * where to feed milk to baby. ** Maybe "feed=*" or "feeding=*"? *** According to Taginfo, those tags are to feed domestic animals. ** Maybe "nursery=*"? *** But this definition is conflict with childcare 2.0 definition. ** possible values are [yes|no]. or others? cheers. -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag babycare?
Thank you for your feedback. > nounours I see. as you say, my opinion has different coverage from childcare 2.0 tagging. So separating them are nice idea. I'll try to make a RFC wiki page. > Martin, Erik > Do we really need a different tag here? Or would it be OK to asume from the wheelchair tags that strollers are OK as well? Are there different technical requirements for accessibility by wheelchairs and strollers? Or is this about legally different situations? As wheelchair and stroller have different width, so situations are a bit different. Basically, stroller's width are smaller than wheelchair's one. So, I think there are some needs where [wheelchair=no] but [stroller=yes]. (e.g. narrow passage in a shop) Similar, main purpose of [ramp=*] is to bicycle. So if a ramp is narrow, it is not accessible to stroller. Based on same logic, as you say, [wheelchair=yes] means certainly [stroller=yes]. So, as technical view, we could treat [wheelchair=yes] as [stroller=yes]. No legal requirement is needed. (at least in my country, Japan) > "breast_feeding"? Nice choice! My main purpose is clarify where to "breast_feed". As I'm not good at English, so your suggestions are very helpful. (Although my baby always cry when feed by bottle, so I need some private space. But this is minor issue :) ) cheers 2013/12/2 Martin Koppenhoefer > 2013/12/2 Satoshi IIDA > >> >> Hi list, >> >> I'm a bit wondering how to tag following babycare amenities. >> Possibly those are additional feature for childcare 2.0 schema, but >> usable with other POIs. >> (e.g. w/ amenity=cafe, toilet, or so.) >> http://wiki.openstreetmap.org/wiki/Proposed_features/childcare2.0 >> >> * where to replace baby's diaper. >> ** according to Taginfo, "diaper=[yes|no|room]" ? >> > > > used very few times (ca. 300). Also alternatives I have checked are used > very few times (e.g. amenity=baby_change 2 times). > > > >> * where to access with stroller/pushchair >> ** according to Taginfo, "stroller=[yes|no|limited]"? >> ** very similar schema as "wheelchair=*". >> > > > Do we really need a different tag here? Or would it be OK to asume from > the wheelchair tags that strollers are OK as well? Are there different > technical requirements for accessibility by wheelchairs and strollers? Or > is this about legally different situations? > > > >> * where to feed milk to baby. >> ** Maybe "feed=*" or "feeding=*"? >> > *** According to Taginfo, those tags are to feed domestic animals. >> > > > maybe "breast_feeding"? I have never needed a tag like this, basically you > can do it everywhere where there isn't too much noise / movement ;-), but > this might be perceived differently in different cultures. > > > > ** Maybe "nursery=*"? > *** But this definition is conflict with childcare 2.0 definition. > ** possible values are [yes|no]. or others? > > > I wouldn't use "nursery" as this seems to refer to something else (a place > to bring your baby so they care for it). > > cheers, > Martin > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag babycare?
> baby-changing tables I saw it in Japan, also. Maybe "diaper = [yes|no|room|table]"? In many JP case, it is set on multi-purpose room in toilet. (with equipments for wheelchair and/or ostmate and so on.) So "diaper = room" means there is such a dedicated, private room. "diaper = table" means that there is no room, but wall-mounted table are there. Considering a more detailed situation, like "Only female toilet has such a equipment". Maybe "female:diaper = [yes|no|room|table]"? In this case, I prefer to take "diaper = limited". To avoid too much information. 2013/12/3 Clifford Snow > > On Mon, Dec 2, 2013 at 12:38 PM, John F. Eldredge wrote: > >> In the USA, an increasing number of restrooms in public and commercial >> buildings have baby-changing tables, usually a wall-mounted, fold-down >> shelf, with a safety strap to make sure a wiggly baby doesn't fall off. Not >> all men's rooms have such tables (I don't know how prevalent they are in >> women's restrooms), so it would be useful to be able to tag the tables when >> they are present. > > > +1 > > > -- > Clifford > > OpenStreetMap: Maps with a human touch > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag babycare?
I made a wiki page for draft. http://wiki.openstreetmap.org/wiki/Proposed_features/babycare I've changed [diaper=*] to [changing_table=*], from your comments. As "changing table" means where to change diaper. I'll change status to RFC in 1-2 days later :) 2013/12/3 Jonathan > +1 > > http://bigfatfrog67.me > > > On 03/12/2013 10:56, Pieren wrote: > >> So I would prefer "amenity=changing_table" as an isolated feature or >> "changing_table=yes" when attached to something else (like >> "amenity=toilets"). Something similar is proposed here: >> http://wiki.openstreetmap.org/wiki/Toilets#Other_proposed_ >> or_emerging_keys_for_toilet_tagging >> >> Pieren >> > > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Baby care
Hi list, I have created a proposal page to describe Baby care schema. It's now on RFC stage with this mail. Please feel free to add your comments on the page. http://wiki.openstreetmap.org/wiki/Proposed_features/babycare Previous discussion log on this ML is found here. https://lists.openstreetmap.org/pipermail/tagging/2013-December/015808.html Thanks! -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Baby care
Thank you your feedback. > your gender restrictions and access tags only work with the baby facility as primary tag. > Adding changing_table:[sex]=* and similar with push_chair to the page is needed. OK, I'll think about combination, then reform the page. > At least one example for both cases would be nice and maybe some pictures. Yes, I'm making samples, and will go to survey once again this weekend to take photos. Regards, 2013/12/13 fly > On 06.12.2013 02:24, Satoshi IIDA wrote: > > > > Hi list, > > > > I have created a proposal page to describe Baby care schema. > > It's now on RFC stage with this mail. > > > > Please feel free to add your comments on the page. > > > > http://wiki.openstreetmap.org/wiki/Proposed_features/babycare > > Your proposal is not really understandable in the way how to use the > access subkeys. > > On top you talk about mainly using the tags as additional keys for other > primary tags but your gender restrictions and access tags only work with > the baby facility as primary tag. > > Adding changing_table:[sex]=* and similar with push_chair to the page is > needed. > > At least one example for both cases would be nice and maybe some pictures. > > Cheers fly > > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
Hi, +1 to Tobias. I feel it needs clarification for this tag scope. I think it was "leisure=hot_spring" once, and switched to "natural=hot_spring". So the main purpose of this scheme is now "natural". Like to represent a geyser or some natural features, it seems. So it is better to make another tag scheme to represent "Onsen" ♨ bathing facility. Many Japanese rural "tourism=hotel" has Onsen amenity. And there is "amenity=public_bath" already. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bath # Some Japanese mappers use "amenity=public_bath" to represent "Sento". # "Sento" is like a spa, but more daily used amenity. # http://en.wikipedia.org/wiki/Sent%C5%8D In my opinion, to represent a "Onsen Hotel", e.g. "tourism=hotel" "amenity=public_bath" "leisure=onsen" or some combination. (yes, this is very draft!) Cheers. 2014-03-04 10:21 GMT+09:00 Tobias Knerr : > On 02.03.2014 13:58, Richard Z. wrote: > >> I have significantly changed > https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring > >> with the intention to revive the proposal - thanks for any comments and > enhancments. > > > > just to clarify, among other changes I changed it from leisure= to > natural= and the > > comments bellow the page are old comments.. > > There would also be a need to map bathing facilities sometimes connected > with such springs, though. I assume this is no longer within the > proposal's scope after the key switch? > > On a related note, can anyone clarify what exactly the ♨ symbol still > mentioned in the proposal refers to exactly? Is it about hot springs in > general or specifically about bathing facilities? Wikipedia (en) > redirects the character to the "Onsen" page. > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
> So the idea is to have > natural=hot_spring - the hole in earth where hot water is comming out I see :) So I prefer to switch the icon from Onsen icon ♨ to another ones. it ♨ maybe to use for leisure/amenity scheme. 2014-03-04 21:10 GMT+09:00 Richard Z. : > On Tue, Mar 04, 2014 at 03:50:30PM +0900, Satoshi IIDA wrote: > > Hi, > > > > +1 to Tobias. > > > > I feel it needs clarification for this tag scope. > > > > I think it was "leisure=hot_spring" once, > > and switched to "natural=hot_spring". > > exactly. > > > So the main purpose of this scheme is now "natural". > > Like to represent a geyser or some natural features, it seems. > > > > So it is better to make another tag scheme to represent "Onsen" ♨ bathing > > facility. > > as you mentioned we already have various methods to map bathing facilities, > thanks for pointing out leisure=public_bath. > > So the idea is to have > natural=hot_spring - the hole in earth where hot water is comming out > + natural=water - if there is a pool of water around it > + water_characteristic - attached to both spring and water > + all other related facilities mapped with their own well known tags such > as tourism=attraction, amenity=public_bath, leisure=beach_resort, > natural=beach, sport=swimming .. please add those which I have forgotten. > > Some of those tags, like swimming need improvement which is independent > from > this proposal. > > water_characteristic is intended to be reusable for natural=spring and all > waterways and other water bodies. > > > Many Japanese rural "tourism=hotel" has Onsen amenity. > > > > # Some Japanese mappers use "amenity=public_bath" to represent "Sento". > > # "Sento" is like a spa, but more daily used amenity. > > # http://en.wikipedia.org/wiki/Sent%C5%8D > > > > In my opinion, to represent a "Onsen Hotel", > > e.g. > > "tourism=hotel" > > "amenity=public_bath" > > "leisure=onsen" > > > > or some combination. (yes, this is very draft!) > > natural=hot_spring is for springs of natural origin. A leisure=onsen is > orthogonal to this so those could be easily combined if the onsen is from > a natural source. Otherwise you would have just leisure=onsen. > > Richard > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
Hello, > * does onsen water always come from natural hot springs? Yes. The water of "onsen" bathing amenity is from always natural. And in precise, it is upper 25'C and must have mineral element. (by law) Not from natural water bathing amenity, it must be called "Sento (bath house, rough meaning "Bath with coin/cheap fee")". In fact, some onsen amenity has no water for their amenity. But they are called as "onsen". Such as "sand bath", or "steam bath (sauna)". BTW their mutual function is "the warmth or water is from natural". > * there are many natural, undelopped hot springs in Japan. > Are those also called "onsen"? In the case of. The common, so called, and main meaning of "onsen" is targeted to represent bathing amenity. By JP law, very natural hot spring with mineral is classified as... * under 25'C water: Kousen (mineral spring) * upper 25'C water: Onsen (hot spring) I could propose following tag combinations to represent "onsen" amenity, but certainly I think they are not your concern ;) Maybe it is better with another proposal, I would like to hear other country's situation. * Onsen Hotel tourism=hotel (or something other, B&B) leisure=onsen * Onsen without lodging amenity=public_bath leisure=onsen * Hotel with Onsen, can use onsen as public_bath also (Higaeri Onsen in Japanese) tourism=hotel (or something other, B&B) amenity=public_bath leisure=onsen * Sento (bathing amenity using water not from hot spring) amenity=public_bath Cheers. 2014-03-05 18:45 GMT+09:00 Richard Z. : > On Wed, Mar 05, 2014 at 10:06:45AM +0900, Satoshi IIDA wrote: > > > So the idea is to have > > > natural=hot_spring - the hole in earth where hot water is comming out > > I see :) > > > > So I prefer to switch the icon from Onsen icon ♨ to another ones. > > it ♨ maybe to use for leisure/amenity scheme. > > another proposal was to use the same symbol as for normal springs in a red > color. > > I can add a leisure=onsen to the proposal, which would take the onsen > symbol. > > But I need clarification regarding the meaning of the word "onsen" : > > * does onsen water always come from natural hot springs? > * there are many natural, undelopped hot springs in Japan. > Are those also called "onsen"? > > Richard > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
Hello, > John > an onsen doesn't necessarily have water available, but, if water is available, it must be from a hot spring? Correct. > Onsen is not English word Exactly. But I don't know the correct word to represent "Onsen" in English. Is "[something]=hot_spring_bath" better? I think, "Onsen" is the very unique word to represent "bathing amenity, that water from natural hot spring". So, I would like to hear the situations of other countries. > Martin > amenity=public_bath + subtag Thank you. It seems nice approach with no conflict to existing scheme. So detailed possible values are ... 1. bath:type = * * [onsen or hot_spring_bath] * [sento or not_from_spring] * [foot_bath] (http://en.wikipedia.org/wiki/Ashiyu) (I'm not a native speaker, suggestions for more proper expression are welcome!) And, to represent existent of "Roten buro(open air bathing amenity)" or not, what about to use following tag? Like the key:open_air. (Although only 3 use.) http://taginfo.openstreetmap.org/keys/open_air 2. bath:open_air = [yes|no] Cheers. 2014-03-06 2:51 GMT+09:00 Martin Koppenhoefer : > > > > Am 05/mar/2014 um 17:56 schrieb Satoshi IIDA : > > > > The water of "onsen" bathing amenity is from always natural. > > And in precise, it is upper 25'C and must have mineral element. (by law) > > > > Not from natural water bathing amenity, it must be called "Sento (bath > house, rough meaning "Bath with coin/cheap fee")". > > In fact, some onsen amenity has no water for their amenity. > > But they are called as "onsen". Such as "sand bath", or "steam bath > (sauna)". > > > > BTW their mutual function is "the warmth or water is from natural". > > > > > * there are many natural, undelopped hot springs in Japan. > > > Are those also called "onsen"? > > In the case of. > > The common, so called, and main meaning of "onsen" is targeted to > represent bathing amenity. > > > > By JP law, very natural hot spring with mineral is classified as... > > * under 25'C water: Kousen (mineral spring) > > * upper 25'C water: Onsen (hot spring) > > > > I could propose following tag combinations to represent "onsen" amenity, > but certainly I think they are not your concern ;) > > Maybe it is better with another proposal, I would like to hear other > country's situation. > > > > * Onsen Hotel > > tourism=hotel (or something other, B&B) > > leisure=onsen > > > > * Onsen without lodging > > amenity=public_bath > > leisure=onsen > > > > * Hotel with Onsen, can use onsen as public_bath also (Higaeri Onsen in > Japanese) > > tourism=hotel (or something other, B&B) > > amenity=public_bath > > leisure=onsen > > > > * Sento (bathing amenity using water not from hot spring) > > amenity=public_bath > > > what about using amenity=public_bath > and then subtype to have specific values according to your legislation and > standards, sth. like > bath:type=onsen / sento etc. > or maybe jp:onsen to give a hint that it is not in English > > cheers, > Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
Thx all! I'm very surprised Onsen is in the Oxford Dictionary :) So I would add following description table and some samples to "amenity=public_bath" page in next a few days. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bath * bath:type = onsen ** amenity has bathing amenity, and the waters from natural hot spring. Common in Japan. http://en.wikipedia.org/wiki/Onsen * bath:type = foot_bath ** foot_bath is usually are a (free) service offered in the front of the onsen to passerbys. It's very shallow, and surrounded by seats, it's like a big sink, rather than a pool. "Ashiyu" in Japanese. http://en.wikipedia.org/wiki/Ashiyu * bath:open_air = [yes|no] ** bathing amenity which has "open air" bath. "Roten buro" in Japanese. http://en.wikipedia.org/wiki/File:Onsen_in_Nachikatsuura,_Japan.jpg > Sento is basically a bath from heated water, right? so basically amenity=public_bath, right? Yes. so I'll make a comment for it as samples. 2014-03-07 22:34 GMT+09:00 Martin Koppenhoefer : > > 2014-03-07 13:12 GMT+01:00 johnw : > > well hot diggity-dog. There we go. > > > > +1, > in your case I think I'd most probably use "onsen" to have a very > specific tag for the very specific feature you are trying to map, something > like "hot spring bath" is not as specific as "onsen" (e.g. also refering to > style and the legal requirements you laid out above: "The water of "onsen" > bathing amenity is from always natural. And in precise, it is upper 25'C > and must have mineral element. (by law)"), an onsen is a japanese bath, and > this is IMHO worth pointing out, just as a restaurant will have typically > warm meals, but there is still a big difference between e.g. japanese and > say russian kitchen. > > cheers, > Martin > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
> John > some onsen are not associated with hot springs, but have hot sand instead. Yes, but they are rare case. Most of onsen are hot water bath. So might be represented by adding following sub_tags. bath:sand_bath=[yes|no] ; if the bathing amenity is sand bath (Suna_yu) or not. bath:sauna=[yes|no] ; if the bathing amenity has sauna facility. (Use it when the main function of the amenity is public_bath. consider using "amenity=sauna" when the main purpose of the amenity is sauna) May seem they are too trivial, but they have an importance to classify onsen amenities. And could be expanded for further trivial expression in the future. (e.g. "effect of the bath", "bath:color", "bath:drinkable", "kakenagashi" or etc.) Cheers. 2014-03-08 2:43 GMT+09:00 John F. Eldredge : > Also, as was pointed out earlier in the thread, some onsen are not > associated with hot springs, but have hot sand instead. > > > -- > *From:* Martin Koppenhoefer > *Sent:* March 7, 2014 7:34:57 AM CST > > *To:* "Tag discussion, strategy and related tools" < > tagging@openstreetmap.org> > *Subject:* Re: [Tagging] Hot springs > > > 2014-03-07 13:12 GMT+01:00 johnw : > >> well hot diggity-dog. There we go. > > > > +1, > in your case I think I'd most probably use "onsen" to have a very > specific tag for the very specific feature you are trying to map, something > like "hot spring bath" is not as specific as "onsen" (e.g. also refering to > style and the legal requirements you laid out above: "The water of "onsen" > bathing amenity is from always natural. And in precise, it is upper 25'C > and must have mineral element. (by law)"), an onsen is a japanese bath, and > this is IMHO worth pointing out, just as a restaurant will have typically > warm meals, but there is still a big difference between e.g. japanese and > say russian kitchen. > > cheers, > Martin > > > -- > > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > > -- > John F. Eldredge -- j...@jfeldredge.com > "Darkness cannot drive out darkness; only light can do that. > Hate cannot drive out hate; only love can do that." > Dr. Martin Luther King, Jr. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Landuse=civic_admin
e (cuvic_admin), it is pretty > obvious that it is a government operated building. > > > > I'm stating that there is a need for a landuse to show purpose for these > heavily trafficked (known) civic buildings, just as we denote the others. > They are more than an office building, just as a university is more than an > office building complex with meeting rooms. > > > > The above is the main point of what I'm trying to say. > > > >> If we were to tag ownership (problematic, might have privacy > implications, could be hard to verify with publicly accessible sources) a > dedicated new tag should be used, e.g. proprietor, owner, property_of or > similar > > > > If we get into building=public, yea. But landuse=civic_admin seems > pretty cut and dry. Which government ( village / town / city / > county-prefecture /state-province / region / federal) is is a question > proprietor= could answer, but thats outside my discussion.. > > > > > > your suggestions and rebuttals have helped me think through my points > and clarify my opinions. Thanks =D > > > > ありがとう (Arigatou) > > John > > > > PS: sorry to hijack leisure=events > > > > > >> cheers, > >> Martin > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hot springs
> not sure but usually the sauna in public baths is somewhat separated so > we might as well tag part of the object as sauna. Yes, this is a very difficult point. I also could not define which is better. Maybe depending on the situation and country. But from Japanese view, Onsen's main feature is as "public_bath" and the type of bath is the sub category. (and from operator's view, it is easier to make query :) ) If the facility announces they are "XXX's sauna" or given name, and they are not onsen amenity, it is better to tag them as "amenity=sauna" even in Japan. 2014-03-10 17:23 GMT+09:00 Richard Z. : > On Mon, Mar 10, 2014 at 01:44:30PM +0900, Satoshi IIDA wrote: > > > John > > > some onsen are not associated with hot springs, but have hot sand > instead. > > Yes, but they are rare case. > > Most of onsen are hot water bath. > > So might be represented by adding following sub_tags. > > > > bath:sand_bath=[yes|no] ; if the bathing amenity is sand bath (Suna_yu) > or > > not. > > that reminds me we also have hay_bath in the Alps, so that would also > fit into it and may be helpful for other cases too. > > > bath:sauna=[yes|no] ; if the bathing amenity has sauna facility. > (Use > > it when the main function of the amenity is public_bath. consider using > > "amenity=sauna" when the main purpose of the amenity is sauna) > > not sure but usually the sauna in public baths is somewhat separated so > we might as well tag part of the object as sauna. > > Richard > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop for baby strollers only
Hi, Almost same discussion when I try to define baby care tagging. :) (sorry for my inactive status.) http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/babycare Baby care tagging is still under RFC, so I'll change my proposal as the result of this discussion. BTW, +1 to subtag scheme for original question. > shop=baby_goods > baby_goods= * Cheers. 2014-04-04 19:45 GMT+09:00 Steve Doerr : > And it appears John Lewis department stores sell strollers: > http://www.johnlewis.com/search/strollers > > Steve > > > On 04/04/2014 11:36, André Riedel wrote: > >> At the moment "stroller" is used for ramps or ways as access condition. >> >> http://taginfo.openstreetmap.org/search?q=stroller >> >> 2014-04-04 12:25 GMT+02:00 Philip Barnes : >> >>> Strollers are, I think, called pushchairs in English. >>> >>> >>> shop=baby_goods >>> >>> baby_goods=push_chairs >>> >>> >>> Phil (trigpoint) >>> >>> -- >>> >>> >>> >>> Sent from my Nokia N9 >>> >>> >>> >>> >>> On 04/04/2014 11:05 Matthijs Melissen wrote: >>> >>> Personally I would use shop=baby_goods, baby_goods=strollers. That way >>> you >>> preserve full detail, and you also accomodate data consumers that don't >>> know >>> about stroller shops. >>> >>> -- Matthijs >>> >>> On 4 Apr 2014 10:50, "André Riedel" wrote: >>> >>>> Should I tag a shop, where I can buy a baby strollers (and only >>>> strollers, nothing more) as shop=baby_goods ? >>>> >>>> Or is it better to use shop=stroller ? >>>> >>>> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbaby_goods >>>> >>>> ___ >>>> Tagging mailing list >>>> Tagging@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/tagging >>>> >>> >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >>> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious-neutral tags needed for religious objects/non-church places
Hi, +1 to "wayside_shrine" + "religion=*". It could cover "Jizou" small buddhist shrines, and "Koushinto" small shrines. And I think those small shrine is covered "wayside_shrine" tag, too. So if possible, wiki descriptions are to be modified to fit more broader definition. Shinto gate is a bit complicated even to Japanese mappers :) We could not find the proper tags to figure it. It means "this is a border between man's ward and gods's ward". So it is similar meaning of "border stone", between Shinto shrine(like church)'s territory & people's. "man_made=shinto_gate" or "man_made=gate" + "religion=shinto" is sounds good for me. (Shinto gate(Torii) is not barrier, city gate or some barriers to block people's traffic.) Hence. man_made=gate is found only 20 samples from taginfo. > cross "***=wayside_cross" + "religion?=celtic" is possible? to represent celtic cross. IMHO, all the cross is not geared for christian. (it is reasonable of default meaning is christian :) ) Off topic. Similar specific tag is "brewery". http://wiki.openstreetmap.org/wiki/Key:brewery It is beer specific description on wiki. But I think it is more broader word to represent brew. (like "brewery" + "brew?=beer, wine, sake or so") Cheers, 2014-06-13 23:29 GMT+09:00 Martin Koppenhoefer : > > 2014-06-13 9:44 GMT+02:00 Volker Schmidt : > > Man_made=cross or historic=wayside_cross similarly is geared for Christian >>> religion, >>> >> >> This is clearly not religion-neutral and I would like to see some >> neutral tags for these objects >> >> > > While I agree that wayside_shrine + religion=* is fine, I don't see why we > should make crosses "religion-neutral". They could be seen as implying > religion=christian, but there really is no problem with having those tags. > > > > >> but there are millions upon millions of Shinto Gates and small figures of >>> Buddha (ones you wouldn't think of as "statues", like the big copper buddha >>> at Kamakura) - but the existing tags are not religious-neutral and paired >>> with the religion tag or a subtag to handle these; ie >>> manmade=ReligiousSymbol, religiousSymbol= Wayside Cross, Shinto Gate, >>> Buddha Statue, Spaghetti Meatball, etc >>> >> > > why not directly tag man_made=shinto_gate? Or sculpture=buddha (together > with religion-tags if you like)? Seems more consistent with our current > tagging approach and is simpler. Not sure if man_made is the best key for > this, I've always seen "man_made" as a category for technical stuff, but on > the other hand it seems there have been inserted also some features which > are of different nature, like "cross", "campanile" (any reason this is not > tagged with building=bell_tower / campanile ?). > http://wiki.openstreetmap.org/wiki/Key:man_made and even > landcover/landuse values (clearcut and cutline). > > Cheers, > Martin > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tag for toilet with ostomate/stoma equipment
Hi, Please let me clarify how to be tagged toilets for "ostomate/stoma equipment" is settled. Here in Japan, some public toilets have such a equipment. http://ja.wikipedia.org/wiki/%E3%82%AA%E3%82%B9%E3%83%88%E3%83%A1%E3%82%A4%E3%83%88 I think it is better to be tagged like "wheelchair =[yes|no]" tag. Any suggestion? Followings are comes to my mind. e.g. ostomy_irrigation = [yes|no] toilet:stoma = [yes|no] toilet:ostomy_irrigation = [yes|no] http://wiki.openstreetmap.org/wiki/Toilet -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Hello from Japan, > @Lukas are the names of the traffic signals/junctions actually used in > addresses (and in principal would be a suitable value for addr:place in an address)? No. We realize the name of traffic signal only for routing and navigation on local district. It is very separated concept from "place" (residence of human kind) tag or "addr:*" (postal delivery) tag. The name of traffic signal is not used as addressing system. And if there are very dense traffic signals, occasionally the names are like... "XZY Conter(Chuo)", "XZY North", "XZY West", or so. # "XZY" is the name of place or district, like Roppongi or Akihabara. Following maybe off topic... Hence, some JP mappers had proposed "place=locality" for old/famous name for mountain path crossing. e.g. "XZY tsuji (辻, crossing)" or "XZY Touge (峠, peak)". They may be acceptable, because we realize them as old/famous place name. But I do not feel that it would not suite for modern traffic_signal system. 2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier : > On 08/25/2014 11:09 PM, Lukas Sommer wrote: > >> In Ivory Coast, you have addresses like “in front of the XYZ crossroad” >> or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort >> of instructions for getting somewhere than an address in the european >> sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” >> will be applied to various houses (usually, when you have arrived, you make >> a phone call to the person that you want to meet, and the person comes to >> the road to search you and help you with the last part of the way – I can >> guarantee you that this is very time-consuming ;-) >> > > That said, people in quite a few African countries have a postal address > (PO box in most cases) distinct from the address of their residence, so the > problem of shoehorning directions in the standard address fields of > European-designed software is side-stepped more often than not. > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] English translations in non-english countries
Hello, > johnw Japan local community had discussed about that on 2014/03. Thread is started here (quite long!) https://lists.openstreetmap.org/pipermail/talk-ja/2013-September/007600.html Summary is * Japan community stop "name = JP (EN)" writing, after 2014/03. * Existing "name = JP (EN)" is switched to "name" + "name:ja" + "name:en", by manually. Mechanical edits are not recommended. * (But as you know, detecting "name = JP (EN)" is very easy those days by using overpass API.) * Most of JP members understand "name = JP (EN)" writing is too bad. But a few insists the bilingual RENDERING on osm.org or on other alternative (apps or tiles or so). * Most of JP members also understand "name = JP (EN)" writing would break the database structure. * Why "name = JP (EN)" writing is still alive on transport? Only for no mappers is enthusiastic about that. At least yet. :) Switching is happen on Place node by some enthusiastic members (as seemed.) As you said, bilingual expression is very important for foreigners. It is better that we could get more "name:* specific" tiles or some vector tile to satisfy this needs. Regards. 2014-09-13 19:59 GMT+09:00 Dave Swarthout : > johnw, > > Let me try to clarify a bit more. In Japan the name tag should contain > ONLY the Japanese language name of the feature. If someone wants to add an > English version they are free to do that but it should be added in a > special tag, i.e., name:en > > That way renderers that wish to show features labeled in English will use > the information in the name:en=* tag while others may use the Japanese name > from the standard name=* tag. It all depends on the audience the renderer > is trying to please. Having a tag with two versions in its value is an > error by this reasoning. > > While the person deleting the parenthetical translation is perhaps being a > bit impolite by not consulting everyone who has added those extra names, he > or she is actually only removing data that is not correct and that will > likely cause problems down the line. In addition, if the practice is as > widespread as you say, contacting everyone doing this bad tagging is simply > too much work. > > As stephan correctly points out, if I were in America I certainly wouldn't > appreciate seeing those parenthetical street names in Thai following the > English names, even in a predominantly Thai neighborhood. > > Dave > > On Sat, Sep 13, 2014 at 5:18 PM, johnw wrote: > >> >> On Sep 13, 2014, at 7:03 PM, Stephan Knauss >> wrote: >> >> No local mapper wants to read München (Munich) on the map. So why should >> Japanese or Chinese mappers want to read something on their map? >> >> >> - if they were using a Japanese only map, then I can understand, but that >> would be pulling from the name:ja= tag, right? >> >> - every single major sign, Street name, Highway exit, Large train station >> identifying sign, City Building label, etc is labeled in English as well as >> Japanese. Every single one of the 2000 or so tollway exits are labeled in >> english, and the hundreds of thousands of blue intersection road signs are >> also printed bi-lingually as well - as a service to the forigners living >> there, as mastering reading and understanding all the Kanji for the various >> place names takes a decade or so of straight practice. >> >> If they sign most everything imaginable that is important in Japanese + >> English, having it mapped that way too seems reasonable. >> >> Understanding that this "JA (en)" schema is bad for the database makes >> sense - but couldn't those also be pulling from the name:*= tags? >> >> >> Javbw >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >> > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] English translations in non-english countries
wow! > https://github.com/gravitystorm/openstreetmap-carto/issues/803 My previous text should be "insisted" (past, at that time). I'll follow the current issue, thanks! 2014-09-14 0:02 GMT+09:00 Matthijs Melissen : > On 13 September 2014 15:41, Satoshi IIDA wrote: > > But a few insists the bilingual RENDERING on osm.org or on other > > alternative (apps or tiles or so). > > This suggestion is in fact currently under discussion: > https://github.com/gravitystorm/openstreetmap-carto/issues/803 > > -- Matthijs > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
> The name belongs to the junction and not to the traffic_signal, or am I wrong ? In Japan, Hokkaido region, there is 4 traffic_signals on 1 junction. Each traffic_signals and 1 junction has different name. Indeed it is rare case. But I think we need Lukas's idea to support it. 2014-09-16 23:38 GMT+09:00 fly : > Am 16.09.2014 08:54, schrieb Lukas Sommer: > > > > > > Would it not be more straight forward to use junction=traffic_signal > in > > Japan and only use highway=traffic_signal for the real lights ? > > > > > > Hm, I’m not sure. It could separete clearly the individual traffic > > signals from the traffic signal system/the covered area. The downside > > would be that we introduce a new tag, and if you are a contributer and > > you want just add such a name to OSM, you have to deal with two > > different taggings: > > – highway=traffic_signals + name=* for simple cases (as currently) > > – junction=traffic_signal + name=* for the complex cases. > > Not sure, but it seems to be more complicate? > > Simply use junction=traffic_signal as addition to > highway=traffic_signal. In long terms, we will have two separate objects. > > The name belongs to the junction and not to the traffic_signal, or am I > wrong ? > > cu fly > > > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Understanding links
If you got any communication loss during the contact, I'll support it. But I think he/she is able to understand English. I saw he/she many time in wiki translation and other OSM related software translation acts. 2014-09-23 2:25 GMT+09:00 fly : > Am 22.09.2014 15:06, schrieb johnw: > > I have a question on highway link roads. > > > > I came across some trunk_links that seemed really out of place today, > but they were recently added by a tagger that usually knows what they are > doing. > > > > https://www.openstreetmap.org/#map=19/36.30046/139.19574 > > > > The frontage road for "local access" to the buildings along the road is > marked as trunk link. > > > > As I understand it, the local access roads would be an unclassified road > with bollards or a kind of barrier at each end, and with trunk links, (or > one way unclassified roads?) that lead onto the actual new trunk road. > > > > This seems like an incorrect use of trunk_links for the frontage road > along the buildings and maybe for the little entrance exit driveways that > connect it to the trunk roads. > > +1 > > I would tag the small links between the parallel highways with > trunk_link and the outside highways look like residential/unclassified > or even service. > > Looks like a tagging mistake, did you get into contact with the user ? > > cu fly > > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] patron saints
+1 to use wikidata. I had once thinking about same purpose. :) https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine But many place of worship in Japanese have multiple dedication gods. And when we would like to express using semi-colon (;), multi-lingual approach would be fail into complex array. e.g. If a shrine dedicates 3 gods. in Japanese Kanji = 天照大御神; 月讀命; 素戔嗚尊 in English = Amaterasu-Oomikami; Tsukuyomi-no-Mikoto; Susanoo-no-Mikoto And each gods has "loc_name", "alt_name", or alternated writings. I was thinking about "dedication:N" (like Addr:N) once, but it is a bit troublesome. 2015-01-29 2:10 GMT+09:00 Martin Koppenhoefer : > > 2015-01-28 17:12 GMT+01:00 André Pirard : > >> Speaking of Vatican, i.e. Roman Catholic Church, Mary is Blessed, not >>> Saint. Her title is Beata Virgo Maria (Beata Vergine Maria in Italian, >>> Blessed Virgin Mary in English). She is an unordinary Blessed, as she and >>> her feasts are more important than those of the Saints; anyway, "Saint >>> Mary" is nothing but a popular name :-) >> >> >> >> Are you sure about this? Because I have heard about "Santissima Madre >> di Dio" (holiest mother of God) >> >> My reply was of course kidding. That, in Simone's terms, the Vatican use >> a popular language ;-) >> The fact is that in French, we use no such words as "Blessed". >> > > > the correct term in French is "bienheureux ou bienheureuse, le > qualificatif donné à une personne qui a été béatifiée" > http://fr.wikipedia.org/wiki/B%C3%A9atification > > cheers, > Martin > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] patron saints
> Isn't there an "official" dedication for a given japanese place of worship? Some has 1 official (main) dedication. Some has plural dedication as official. e.g. Katori Jingu Shrine = 経津主大神 (Futsunushi-no-Kami) http://ja.wikipedia.org/wiki/%E9%A6%99%E5%8F%96%E7%A5%9E%E5%AE%AE http://en.wikipedia.org/wiki/Katori_Shrine http://ja.wikipedia.org/wiki/%E7%B5%8C%E6%B4%A5%E4%B8%BB%E7%A5%9E http://en.wikipedia.org/wiki/Futsunushi > Wikidata & Notability Each Japanese shrine has always their dedication god(s). Even pretty small shrine (such as wayside_shrine) has. If we use wikidata, Notability of Wikipedia might be problematic. Maybe it is better to make a brand new dataset for this purpose. (too heavy, indeed) > Sorry that I missed your proposal. Do not mind :) Let's make better approach together! 2015-01-30 18:40 GMT+09:00 Jo : > I think that when it gets really that complex, it's best to create a > wikidata item for the shrine (and probably a Wikpedia page as well, I guess > at least on ja.WP they are noteworthy enough to deserve a page), then > simply refer to that using the wikidata tag itself. > > and maybe a comma delimited list of wikidata Q-refs in the > dedication:wikidata tag, for people who want to rely on only OSM data for > statistics purposes. > > Jo > > > > 2015-01-29 13:24 GMT+01:00 Satoshi IIDA : > >> >> +1 to use wikidata. >> I had once thinking about same purpose. :) >> https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine >> >> But many place of worship in Japanese have multiple dedication gods. >> And when we would like to express using semi-colon (;), >> multi-lingual approach would be fail into complex array. >> >> e.g. >> If a shrine dedicates 3 gods. >> in Japanese Kanji = 天照大御神; 月讀命; 素戔嗚尊 >> in English = Amaterasu-Oomikami; Tsukuyomi-no-Mikoto; Susanoo-no-Mikoto >> >> And each gods has "loc_name", "alt_name", or alternated writings. >> I was thinking about "dedication:N" (like Addr:N) once, but it is a bit >> troublesome. >> >> >> >> 2015-01-29 2:10 GMT+09:00 Martin Koppenhoefer : >> >>> >>> 2015-01-28 17:12 GMT+01:00 André Pirard : >>> >>>> Speaking of Vatican, i.e. Roman Catholic Church, Mary is Blessed, not >>>>> Saint. Her title is Beata Virgo Maria (Beata Vergine Maria in Italian, >>>>> Blessed Virgin Mary in English). She is an unordinary Blessed, as she and >>>>> her feasts are more important than those of the Saints; anyway, "Saint >>>>> Mary" is nothing but a popular name :-) >>>> >>>> >>>> >>>> Are you sure about this? Because I have heard about "Santissima Madre >>>> di Dio" (holiest mother of God) >>>> >>>> My reply was of course kidding. That, in Simone's terms, the Vatican >>>> use a popular language ;-) >>>> The fact is that in French, we use no such words as "Blessed". >>>> >>> >>> >>> the correct term in French is "bienheureux ou bienheureuse, le >>> qualificatif donné à une personne qui a été béatifiée" >>> http://fr.wikipedia.org/wiki/B%C3%A9atification >>> >>> cheers, >>> Martin >>> >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >>> >> >> >> -- >> Satoshi IIDA >> mail: nyamp...@gmail.com >> twitter: @nyampire >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >> > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=confectionery / pastry / candy / sweets
There are Japanese "non-baked" confectioneries. (I believe similar confectioneries in other countries. esp. in Asia) http://en.wikipedia.org/wiki/Wagashi If we take only a) plan, I'm afraid of we could not represent cultural variations. +1 to Janko's a+b), and to express the specialty, moltonel's "confectionery:FOO=yes confectionery:BAR=yes". 2015-05-12 0:24 GMT+09:00 Janko Mihelić : > I would be more in favor of a+b) because you might want to tag a place > with shop=pastry because 95% of their assortiment is pastry, but they have > 5% candy so you add candy=yes. > > Janko > > pon, 11. svi 2015. 17:12 Brad Neuhauser je > napisao: > >> In my experience, most places that sell pastries would be better tagged >> as bakery. Even if they only sell pastries (ie no bread), they do have to >> bake them, right? :) >> >> On Mon, May 11, 2015 at 5:43 AM, moltonel 3x Combo >> wrote: >> >>> On 11/05/2015, Martin Koppenhoefer wrote: >>> > I believe there is some overlap between the shop values >>> > >>> > confectionery >>> > pastry >>> > candy >>> > sweets >>> > >>> > shop=confectionery is used much more often than the other 3 (10K vs. >>> 300 >>> > vs. 100 vs. 50) and is likely covering all of these, but is quite >>> generic. >>> > For the very reason it can be used for both: pastry (baker's >>> confections) >>> > and candy (sugar confections), it is often less useful IMHO (at least >>> > without subtag, which is currently not documented). "often", because in >>> > some countries these tend to be distinct shops, but in other contexts >>> there >>> > might be shops that are offering both kind. >>> > >>> > If you are looking for sugar confections or baker's confections, >>> finding a >>> > shop that only sells the other variant of confections will not be >>> helpful >>> > but rather a big annoyance. >>> > >>> > From previous discussions on this matter I believe to remember that >>> > "pastry" is actually not covering the entire subset of baker's >>> confections, >>> > so the term might be less appropriate. >>> > >>> > "sweets" is not very specific neither, is not defined in the wiki and >>> can >>> > maybe cover both, candy and pastry, or might be a synonym for >>> candy/sugar >>> > confections (I am not sure about this, would be nice to hear what the >>> > natives say). It also doesn't seem to add any additional information >>> with >>> > respect to confectionery, so I would suggest to deprecate its use >>> > completely. >>> > >>> > I think we could deal with this situation in several ways: >>> > >>> > a) use confectionery, pastry and candy as competing top-level tags and >>> > suggest to be the most specific where possible (i.e. aim to have only >>> mixed >>> > shops tagged with the generic confectionery tag and recommend the more >>> > specific pastry and candy tags where applicable). >>> > >>> > b) recommend to only use confectionery as the main top level tag and >>> use >>> > subtags like bakers_confectionery=yes and/or sugar_confectionery=yes to >>> > make the distinction >>> > >>> > c) your suggestion here >>> > >>> > Personally I favor b). What do you think? >>> >>> My initial reaction was "there's no overlap between pastry and >>> confectionery, they are totally different things". Some cultural >>> background: in France, shops selling candys are very rare, but shops >>> selling pastries are very common because bread shops are everywhere >>> and usually also sell pastries and danishes. Pastry-only shops are >>> quite rare. See also shop=patisserie (62 uses). >>> >>> But using shop=confectionery and refining that into raw sug^W^Wsubtags >>> makes sense too. >>> >>> For the subtag itself, I'm not a fan of FOO_confectionery=yes: I think >>> that confectionery=FOO follows established tag-creation best practices >>> better. It's used a bit in the db already. And if one needs to tag >>> multiple types, either "confectionery=FOO;BAR" or >>> "confectionery:FOO=yes confectgionery:BAR=yes" works for me (but I >>> prefer the later). >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Help undoing an admin level 3 edit to Japan
Hello, +1 to Javbw. I'm completely same opinion & feeling of you. "admin_level=3" is reserved bit for future "state". I guess Japanese community has consensus on it, and AFAIK there was no further discussion had be done. I've took a look on "admin_level=3" edits. Mainly done by him. http://www.openstreetmap.org/user/etajin sample. http://www.openstreetmap.org/relation/532759 He did many boundary & place & national park edits, including some mistakes. I had contacted him once via changeset comment, but I could not have response. (He can read Japanese, and meybe English.) I'll mention this issue to talk-ja. If you could got response from him, please tell us. Regards, 2015-08-11 22:25 GMT+09:00 John Willis : > > > > On Aug 11, 2015, at 9:35 PM, Andy Townsend wrote: > > From there I'd link to where the Japanese community discusses boundaries > (which might be the wiki, but often is somewhere else). > > > Thanks for the help Andy I'll look over it in the morning. ^^ > > The only "official" thing I have, and where I got the information for the > admin level, is the wiki page I linked to for Japan tagging. > > http://wiki.openstreetmap.org/wiki/Japan_tagging#Boundary > > Thanks again for the links! > > Javbw > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] BCP 47, Multilingual Standard and OSM
Hello list,
Please let me clarify :)
I wonder if there is some consensus on multilingual standard about using
BCP 47?
https://tools.ietf.org/html/bcp47
In Japan, we have been using "name:ja_rm" or "name:ja_kana" for expression
of Roman writing or pronunciation, traditionally (since around 2010?).
But currently, "name:ja_rm" or some other tags are going to be treated as
deprecated.
https://wiki.openstreetmap.org/wiki/Names
Problems are...
1. existing tags on objects ("name:ja_rm" and so on)
Maybe mechanical or mass edit would be needed.
I guess this would be huge cost for separation & need cost of existing
Mappy app clients.
2. name:zh
Chinese language is represented as "zh" in ISO639-1.
But as using BCP 47, it is separated in several scheme.
(such as traditional writing in Taiwan, and simplified one in PRC.)
Currently some Chinese languages are intermingled in one "zh" scheme.
https://taginfo.openstreetmap.org/keys/name%3Azh#values
Some discussion are already rising on Taiwan mappers.
https://osmtw.hackpad.com/RFC-Multilingual-names-ngewyizFYzN
Your comments welcome!
P.S.
Related information.
https://lists.openstreetmap.org/pipermail/talk/2012-April/062803.html
https://lists.openstreetmap.org/pipermail/tagging/2012-August/011005.html
http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names#Standard_language_codes
--
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Living street" in Japan
Hello, Just a information. We had a similar discussion on talk-ja. (2016 oct) We could not reach the detailed consensus at that time. But there are some rare case to match "highway=living_street" such as the one named "Zone 30" public highway/road in Japanese situation. * thread: https://lists.openstreetmap.org/pipermail/talk-ja/2016-October/009532.html Hoping this could be useful. 2017-03-30 12:28 GMT+09:00 tomoya muramoto : > OK I will send a message to him. > muramoto > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
