Max wrote: 2. Many POIs in Korea are outdated and not valid any more. In the > problematic import, there are all kinds of hospitals and clinics that are > closed by now. Editing those would "mark them like new" and it would not be > visible immedately that they might not be valid any more >
Don’t agree. First, age or last modified time of a POI don’t represent correctness of the POI. Second, if the importing was problematic, then we should revert the problematic importing rather than keep them without modification. No common renderer “mark them like new” or marks POI as maybe-incorrect base on their age or last modified time. It is information behind map. As well as, normal user want to know point-of-interest, not history of point-of-interest. Even an expert user want to see history, but he/she can immediate identify the last change is mechanical renaming because there must be a comment. As a mapper, I modified POIs because I knew information of the POIs were incorrect. Latest confirmed date(?) or something like that can be useful for users, however it must exist as a separate information if needed. We cannot know such information from history of POI itself and should not. 2017-03-04 21:54 GMT+09:00 느림보 <nri...@gmail.com>: > You are right. For the name of roads in South Korea, Romanization has > precedence over translation. It is defined in 공공 용어의 영어 번역 및 표기 지침 (English > translation and marking instructions of public terms, > https://drive.google.com/file/d/0B-H3vA9-nLFkQWNLYjJsN00tRG8/view?usp= > sharing). > > > > Korean Government adopted street-based address. For proper working as > Address, there should be minimum differences between written forms and it > should be easy to convert between them. If translation of road name is > allowed, it will hurt address system of South Korea, because there can be > lots of alternatives for translation. > > > > Translation vs. Romanization -- they should be made case-by-case, but for > the name of road, I think proper one is Romanization. ‘name:en’ can exist > but it should has the same value as ‘name:ko_rm.’ > > > > > > 2017-03-04 21:16 GMT+09:00 Robert Helvie <alim...@gmail.com>: > >> The ideas here are good, but I have a problem with the idea that the >> Korean names "should" be translated. >> >> I have come across numerous examples where a street name COULD be >> translated, for example something like "대학로" could be translated to >> "University street"; however, the English on the actual street sign is not >> translated and says "Daehak-ro". >> In a situation like this, shouldn't the name:en tag still exist and be >> "Daehak-ro"? In this case, the name:ko_rm=romanized would be the same, but >> certainly not in all cases. >> >> There is at least one service I know of that uses the name:en tag to >> create maps using OSM data. And, I expect future renderers will need to >> access specific language tags when things get to the point where you can >> choose a language and have the map rendered on the fly in your language. >> >> If you just start translating all street names and POI names, then anyone >> using an English rendered map to find places in Korea is going to have a >> pretty hard time unless they speak Korean. Sure, it will obviously take >> time to get the actual signage into OSM, but I think that route is better >> than just translating things and entering a lot of unrepresentative data. >> >> Robert >> >> >> *"We should give meaning to life, not wait for life to give us meaning. "* >> ~ unknown >> --- >> >> On Sat, Mar 4, 2017 at 8:45 PM, 느림보 <nri...@gmail.com> wrote: >> >>> It might be useful for foreigners to have combination name as 한국어 >>> (English). However, as a local mapper I don’t want see (English) because >>> they don’t give additional information to Korean people, as well as they >>> block displaying of other POIs by taking additional space. To make matters >>> worse, English name is longer than original Korean name, generally. >>> >>> >>> >>> Andrew said that “…as an English speaker living in Korea it is very >>> useful for me…”. So, I looked after several online services and OsmAnd to >>> see how they looks. In most cases, they are using local name (name tag) >>> only. MapQuest prefer English than local name and OsmAnd has function >>> override language, but they don’t give two languages, too. >>> >>> >>> >>> I also found two sites displaying two languages (Max already introduced >>> one of them.) They display Korean name and ‘foreign name’ line-by-line. For >>> me, it is more readable than wrapping English name by parenthesis and looks >>> like more proper way handling name tags. >>> >>> https://www.openstreetmap.de/karte.html?zoom=10&lat=49.99303 >>> &lon=18.83157&layers=B000TT >>> >>> http://maps.sputnik.ru/?lat=37.536410466671626&lng=127.00847 >>> 625732423&zoom=12 >>> >>> >>> >>>> name=한국어 and name:ko=한국어 are kind of redudnant, but it is probably >>>> neccessary to help transitioning. Also it is the same way in Japan. >>>> >>> >>> Agree, I hesitated making duplicated data at the first time but I >>> accepted this rule for that reason. It looks like that it is accepted >>> globally. More than half of 20 busiest airports have duplicated name tags. >>> >>> >>> >>>> ko_rm should actually be renamed in bulk to ko-Latn, possibly in >>>> cooperation and discussion with the japanese community who have the same >>>> problem with ja_rm that should be ja-Latn >>>> >>>> See here: https://wiki.openstreetmap.org/wiki/Names#Localization >>>> the next paragraph in this wiki page is interesting too. We should >>>> avoid transliterations. According to this rule 90% of the name:ko_rm and >>>> name:en tags should go. >>>> >>> >>> I think Romanized name is useful when the name doesn’t have meaning >>> part. If a name doesn’t have meaning part, then there will be no proper >>> translated name, too. In this case, only ko-Latn tag (or ko_rm) holds >>> foreigner friendly characters properly. In this reason, I don’t hesitate to >>> add ko-Latn to administrative units. However, I think Romanization should >>> be avoided if a name has meaning part. (I already expressed my opinion in >>> previous thread, but again…) >>> >>> 1) Romanization of Korean is not simple transliteration. It is >>> difficult to guarantee correctness of Romanized name. First principle of >>> Romanization is “Romanization is based on standard Korean pronunciation.” >>> Finding proper pronunciation of Korean words is difficult job even native >>> Koreans. As well as, “Proper names such as personal names and those of >>> companies may continue to be written as they have been previously.” Only >>> owner of the property can give proper Romanized name. >>> See http://www.korean.go.kr/front_eng/roman/roman_01.do >>> >>> 2) Even it is my personal experiment, translated name is readable >>> than Romanized name. I think it is better to encourage translate rather >>> than Romanize. >>> >>> 2017-03-04 18:09 GMT+09:00 Max <abonneme...@revolwear.com>: >>> >>>> On 2017년 03월 04일 09:39, Andrew Errington wrote: >>>> >>>>> I agree that name tagging should be fixed, but I don't agree that we >>>>> have a solution yet. >>>>> >>>> Indeed >>>> >>>> Firstly, name=* might not be in Korean language. I can give several >>>>> examples where the name of something in Korea (for example, a shop, or >>>>> a >>>>> restaurant) is in Chinese, English, or French. So, I think we should >>>>> not insist that name=* must always be Korean. >>>>> >>>> Very good point. >>>> >>>> However, it is useful to make a record of the Korean name in name:ko=* >>>>> even if it is the same as name=*. The reason for this is so that we >>>>> can >>>>> make a multilingual map. >>>>> >>>> Agreed >>>> >>>> I agree that if name=* is a combination of "Korean (English)" it should >>>>> be changed, but as an English speaker living in Korea it is very useful >>>>> for me, so I am reluctant to make that change. And if it's useful for >>>>> me, it is probably useful for other people. >>>>> >>>> While I generally sympathize, I think this is a bit of an colonialzing >>>> view onto Korea. Hell would break loose if someone would think it's >>>> appropriate to tag every item in the states with Korean or Arabic >>>> transcriptions. >>>> >>>> This brings me to another important point, we must think of the people >>>>> who will be using the data. We must provide data which is properly >>>>> tagged so that the map renderer can choose the correct tag to label >>>>> every road or street or building for the language chosen by the user. >>>>> I >>>>> think the reason why name=* was a combination of "Korean (English)" was >>>>> because we didn't have renderers that could render in different >>>>> languages. Maybe we still don't, but we should be thinking of the >>>>> future, as well as the present. >>>>> >>>> That's very true. I hope these multilingual renderers will appear soon, >>>> so we have one less reason to slow down the transition. >>>> Maybe an intermediate solution would be to have a Korean render style? >>>> openstreetmap.kr ? just like the german style at >>>> https://www.openstreetmap.de/karte.html >>>> >>>> I think we have to have a full discussion before you run your automated >>>>> script. We should also remember that there is no urgency, and we >>>>> should >>>>> not be hasty. >>>>> >>>> >>>> _______________________________________________ >>>> Talk-ko mailing list >>>> Talk-ko@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-ko >>>> >>> >>> >>> _______________________________________________ >>> Talk-ko mailing list >>> Talk-ko@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-ko >>> >>> >> >> _______________________________________________ >> Talk-ko mailing list >> Talk-ko@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ko >> >> >
_______________________________________________ Talk-ko mailing list Talk-ko@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ko
