<div dir="ltr">
<p class="MsoNormal"><span lang="EN-US">FYI,<br>
<br>
</span>공공 용어의 영어 번역 및 표기 지침<span lang="EN-US"> (English translation and marking
instructions for public terms) was published by </span>문화체육관광부<span lang="EN-US">
(Ministry of Culture, Sports and Tourism).</span></p>
<p class="MsoNormal"><span lang="EN-US">Reference: <a href="http://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000035680">http://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000035680</a></span></p>
<p class="MsoNormal">문화재명칭 영문표기 기준 규칙<span lang="EN-US"> (English marking instruction
of culture properties) was published by </span>문화재청<span lang="EN-US"> (Culture
Heritage Administration).</span></p>
<p class="MsoNormal"><span lang="EN-US">Reference: <a href="http://www.law.go.kr/admRulLsInfoP.do?admRulSeq=2100000005900">http://www.law.go.kr/admRulLsInfoP.do?admRulSeq=2100000005900</a></span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">I updated instructions into Google Drive
because they were saved as HWP files. (A file-type for a commercial word processor),
but I replaced then into web pages because I found alternates</span></p>
</div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-05 17:57 GMT+09:00 Changwoo Ryu <span dir="ltr"><<a href="mailto:cwryu@debian.org" target="_blank">cwryu@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The name tag is for local default name (data), not exactly for<br>
preferred label form (visibility).<br>
<br>
Like other people have said, we can't just choose the name tag<br>
convention based on rendering preference. Leave the job to the map<br>
renderers.<br>
<div class="HOEnZb"><div class="h5"><br>
2017-03-05 17:00 GMT+09:00 최규성 <<a href="mailto:kyusung.choi@gmail.com">kyusung.choi@gmail.com</a>>:<br>
><br>
> References are the posts by Yongmin, Nrimbo, Andrew Errington and Robert<br>
> Helvie.<br>
><br>
> I'm very interested in this dialog thinking it important. However, it makes<br>
> me confused on what the point is. To me, the points are coming as<br>
> 1) How to Romanize Korean tags<br>
> 2) Labeling convention for place names (or name field).<br>
><br>
> If the above is correct, let me suggest my opinion as follows.<br>
><br>
> 1. How to Romanize Korean Tags<br>
><br>
> Regarding this issue, there is an agreed practice in Korea. Korean<br>
> government has led the standardization that should be officially applied to<br>
> road signs, national basemaps, etc. The Romanization standard is established<br>
> by National Institute of Korean Language (NIKL), which is found as below:<br>
>> [In Korean] -<br>
>> <a href="https://www.korean.go.kr/front/page/pageView.do?page_id=P000148&mn_id=99" rel="noreferrer" target="_blank">https://www.korean.go.kr/<wbr>front/page/pageView.do?page_<wbr>id=P000148&mn_id=99</a><br>
>> [In English] - <a href="https://www.korean.go.kr/front_eng/roman/roman_01.do" rel="noreferrer" target="_blank">https://www.korean.go.kr/<wbr>front_eng/roman/roman_01.do</a><br>
><br>
> (Nrimbo's Google Drive document seems to be consistent with this though lack<br>
> of source referral.)<br>
><br>
> For use with mapping, a practical guideline is prepared by National<br>
> Geographic Information Institute (NGII), the national mapping agency of<br>
> Korea. It is well documented as linked below.<br>
>> Toponymic guidelines for map and other editors for international use:<br>
> <a href="https://www.dropbox.com/s/hxngjd18jtbsm1q/Toponymy_Guidelines.pdf?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/<wbr>hxngjd18jtbsm1q/Toponymy_<wbr>Guidelines.pdf?dl=0</a><br>
><br>
> According to this, we can decide whether we have to choose 'Daehak-ro' or<br>
> 'University street'. My answer is 'Daehak-ro'.<br>
><br>
> Here is one interesting online map service that exemplarily shows the<br>
> Romanized names. It is a Road Name Address Information System service by<br>
> Korean government - <a href="http://m1.juso.go.kr/eng/standardmap/MapIndex.do" rel="noreferrer" target="_blank">http://m1.juso.go.kr/eng/<wbr>standardmap/MapIndex.do</a> . Here,<br>
> we can identify how "Daehak-ro" and other street names are labelled.<br>
><br>
> But, I have a concern on how we make the awareness sure to every OSM mapper<br>
> of this standardized Romanization practice.<br>
><br>
> 2. Labeling convention for place names (or name field)<br>
><br>
> I strongly support the idea of labelling the name by Korean and English<br>
> combination.<br>
><br>
> As a result, it is against the idea of Yongmin. If OSM was designed only for<br>
> Koreans and by Koreans, it would have been agreeable. But, as many of us<br>
> would agree, OSM is designed as a global map for everyone in the world. The<br>
> map of Italy region is also lack of something. The Korean who can't<br>
> understand Italian (like me) becomes illiterate when I see it, which needs<br>
> to be improved. In this regard, I evaluate that OSM labeling style for Korea<br>
> region is more advanced than that for Italy.<br>
><br>
> But, I have additional request of modifying the current style. My suggestion<br>
> is to separate Korean\English by line breaker AND to remove the parentheses<br>
> (round brackets). The parenthesis is useless.<br>
><br>
> We can find best practices in the global map services like ArcGIS Online Map<br>
> or Google Maps.<br>
><br>
> The example of ArcGIS Online map is linked here -<br>
> <a href="https://www.dropbox.com/s/vslwnpyhixw1off/Ex_agol.jpg?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/<wbr>vslwnpyhixw1off/Ex_agol.jpg?<wbr>dl=0</a><br>
><br>
> This shows like this ---<br>
> 강남역<br>
> Gangnam Station<br>
><br>
> In Google Maps, separate languages are labelled in two lines one by one<br>
> WITHOUT parentheses.<br>
><br>
> I hope this would help to resolve the issue. If I missed any other arguing<br>
> points, please advise me.<br>
><br>
> Best regards,<br>
><br>
><br>
> Kyu-sung Choi<br>
><br>
> 2017-03-05 15:14 GMT+09:00 <<a href="mailto:talk-ko-request@openstreetmap.org">talk-ko-request@<wbr>openstreetmap.org</a>>:<br>
>><br>
>> Send Talk-ko mailing list submissions to<br>
>> <a href="mailto:talk-ko@openstreetmap.org">talk-ko@openstreetmap.org</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
>> or, via email, send a message with subject or body 'help' to<br>
>> <a href="mailto:talk-ko-request@openstreetmap.org">talk-ko-request@openstreetmap.<wbr>org</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a href="mailto:talk-ko-owner@openstreetmap.org">talk-ko-owner@openstreetmap.<wbr>org</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of Talk-ko digest..."<br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: Fixing laguage-mixed name tag in Korean region (Yongmin H.)<br>
>> 2. Re: Fixing laguage-mixed name tag in Korean region (느림보)<br>
>><br>
>><br>
>> ---------- 전달된 메시지 ----------<br>
>> From: "Yongmin H." <<a href="mailto:lists@revi.pe.kr">lists@revi.pe.kr</a>><br>
>> To: OpenStreetMap Korea <<a href="mailto:talk-ko@openstreetmap.org">talk-ko@openstreetmap.org</a>><br>
>> Cc:<br>
>> Bcc:<br>
>> Date: Sun, 5 Mar 2017 00:10:39 +0900<br>
>> Subject: Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region<br>
>> I don't agree with this. When I see the Milan, Italy's map, I expect<br>
>> things to have name = value in Italian, not Italian(English). (And it is<br>
>> done that way[1].) It shouldn't be different just because it is Korea. If<br>
>> renderer doesn't show the name correctly in their given set language(say,<br>
>> English), that's renderer's fault, not the data's fault.<br>
>><br>
>> [1]: <a href="https://osm.org/go/0CjFi4mPI-" rel="noreferrer" target="_blank">https://osm.org/go/0CjFi4mPI-</a><br>
>><br>
>> --<br>
>> Yongmin<br>
>><br>
>> Sent from my iPhone<br>
>> <a href="https://wp.revi.blog" rel="noreferrer" target="_blank">https://wp.revi.blog</a><br>
>> Please note that this address is list-only address and any non-mailing<br>
>> list mails will be treated as spam.<br>
>> Please use <a href="https://encrypt.to/0x947f156f16250de39788c3c35b625da5beff197a" rel="noreferrer" target="_blank">https://encrypt.to/<wbr>0x947f156f16250de39788c3c35b62<wbr>5da5beff197a</a>.<br>
>><br>
>> 2017. 3. 4. 17:39 Andrew Errington <<a href="mailto:erringtona@gmail.com">erringtona@gmail.com</a>> 작성:<br>
>><br>
>> I agree that if name=* is a combination of "Korean (English)" it should be<br>
>> changed, but as an English speaker living in Korea it is very useful for me,<br>
>> so I am reluctant to make that change. And if it's useful for me, it is<br>
>> probably useful for other people.<br>
>><br>
>> This brings me to another important point, we must think of the people who<br>
>> will be using the data. We must provide data which is properly tagged so<br>
>> that the map renderer can choose the correct tag to label every road or<br>
>> street or building for the language chosen by the user. I think the reason<br>
>> why name=* was a combination of "Korean (English)" was because we didn't<br>
>> have renderers that could render in different languages. Maybe we still<br>
>> don't, but we should be thinking of the future, as well as the present.<br>
>><br>
>><br>
>><br>
>> ---------- 전달된 메시지 ----------<br>
>> From: "느림보" <<a href="mailto:nrimbo@gmail.com">nrimbo@gmail.com</a>><br>
>> To: OpenStreetMap Korea <<a href="mailto:talk-ko@openstreetmap.org">talk-ko@openstreetmap.org</a>><br>
>> Cc:<br>
>> Bcc:<br>
>> Date: Sun, 5 Mar 2017 15:14:04 +0900<br>
>> Subject: Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region<br>
>><br>
>> Max wrote:<br>
>><br>
>>> 2. Many POIs in Korea are outdated and not valid any more. In the<br>
>>> problematic import, there are all kinds of hospitals and clinics that are<br>
>>> closed by now. Editing those would "mark them like new" and it would not be<br>
>>> visible immedately that they might not be valid any more<br>
>><br>
>><br>
>> Don’t agree. First, age or last modified time of a POI don’t represent<br>
>> correctness of the POI. Second, if the importing was problematic, then we<br>
>> should revert the problematic importing rather than keep them without<br>
>> modification.<br>
>><br>
>><br>
>><br>
>> No common renderer “mark them like new” or marks POI as maybe-incorrect<br>
>> base on their age or last modified time. It is information behind map. As<br>
>> well as, normal user want to know point-of-interest, not history of<br>
>> point-of-interest. Even an expert user want to see history, but he/she can<br>
>> immediate identify the last change is mechanical renaming because there must<br>
>> be a comment.<br>
>><br>
>><br>
>><br>
>> As a mapper, I modified POIs because I knew information of the POIs were<br>
>> incorrect. Latest confirmed date(?) or something like that can be useful for<br>
>> users, however it must exist as a separate information if needed. We cannot<br>
>> know such information from history of POI itself and should not.<br>
>><br>
>><br>
>> 2017-03-04 21:54 GMT+09:00 느림보 <<a href="mailto:nrimbo@gmail.com">nrimbo@gmail.com</a>>:<br>
>>><br>
>>> You are right. For the name of roads in South Korea, Romanization has<br>
>>> precedence over translation. It is defined in 공공 용어의 영어 번역 및 표기 지침 (English<br>
>>> translation and marking instructions of public terms,<br>
>>> <a href="https://drive.google.com/file/d/0B-H3vA9-nLFkQWNLYjJsN00tRG8/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/0B-H3vA9-<wbr>nLFkQWNLYjJsN00tRG8/view?usp=<wbr>sharing</a>).<br>
>>><br>
>>><br>
>>><br>
>>> Korean Government adopted street-based address. For proper working as<br>
>>> Address, there should be minimum differences between written forms and it<br>
>>> should be easy to convert between them. If translation of road name is<br>
>>> allowed, it will hurt address system of South Korea, because there can be<br>
>>> lots of alternatives for translation.<br>
>>><br>
>>><br>
>>><br>
>>> Translation vs. Romanization -- they should be made case-by-case, but for<br>
>>> the name of road, I think proper one is Romanization. ‘name:en’ can exist<br>
>>> but it should has the same value as ‘name:ko_rm.’<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> 2017-03-04 21:16 GMT+09:00 Robert Helvie <<a href="mailto:alimamo@gmail.com">alimamo@gmail.com</a>>:<br>
>>>><br>
>>>> The ideas here are good, but I have a problem with the idea that the<br>
>>>> Korean names "should" be translated.<br>
>>>><br>
>>>> I have come across numerous examples where a street name COULD be<br>
>>>> translated, for example something like "대학로" could be translated to<br>
>>>> "University street"; however, the English on the actual street sign is not<br>
>>>> translated and says "Daehak-ro".<br>
>>>> In a situation like this, shouldn't the name:en tag still exist and be<br>
>>>> "Daehak-ro"? In this case, the name:ko_rm=romanized would be the same, but<br>
>>>> certainly not in all cases.<br>
>>>><br>
>>>> There is at least one service I know of that uses the name:en tag to<br>
>>>> create maps using OSM data. And, I expect future renderers will need to<br>
>>>> access specific language tags when things get to the point where you can<br>
>>>> choose a language and have the map rendered on the fly in your language.<br>
>>>><br>
>>>> If you just start translating all street names and POI names, then<br>
>>>> anyone using an English rendered map to find places in Korea is going to<br>
>>>> have a pretty hard time unless they speak Korean. Sure, it will obviously<br>
>>>> take time to get the actual signage into OSM, but I think that route is<br>
>>>> better than just translating things and entering a lot of unrepresentative<br>
>>>> data.<br>
>>>><br>
>>>> Robert<br>
>>>><br>
>>>> "We should give meaning to life, not wait for life to<br>
>>>> give us meaning. "<br>
>>>> ~ unknown<br>
>>>> ---<br>
>>>><br>
>>>> On Sat, Mar 4, 2017 at 8:45 PM, 느림보 <<a href="mailto:nrimbo@gmail.com">nrimbo@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> It might be useful for foreigners to have combination name as 한국어<br>
>>>>> (English). However, as a local mapper I don’t want see (English) because<br>
>>>>> they don’t give additional information to Korean people, as well as they<br>
>>>>> block displaying of other POIs by taking additional space. To make matters<br>
>>>>> worse, English name is longer than original Korean name, generally.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Andrew said that “…as an English speaker living in Korea it is very<br>
>>>>> useful for me…”. So, I looked after several online services and OsmAnd to<br>
>>>>> see how they looks. In most cases, they are using local name (name tag)<br>
>>>>> only. MapQuest prefer English than local name and OsmAnd has function<br>
>>>>> override language, but they don’t give two languages, too.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> I also found two sites displaying two languages (Max already introduced<br>
>>>>> one of them.) They display Korean name and ‘foreign name’ line-by-line. For<br>
>>>>> me, it is more readable than wrapping English name by parenthesis and looks<br>
>>>>> like more proper way handling name tags.<br>
>>>>><br>
>>>>><br>
>>>>> <a href="https://www.openstreetmap.de/karte.html?zoom=10&lat=49.99303&lon=18.83157&layers=B000TT" rel="noreferrer" target="_blank">https://www.openstreetmap.de/<wbr>karte.html?zoom=10&lat=49.<wbr>99303&lon=18.83157&layers=<wbr>B000TT</a><br>
>>>>><br>
>>>>><br>
>>>>> <a href="http://maps.sputnik.ru/?lat=37.536410466671626&lng=127.00847625732423&zoom=12" rel="noreferrer" target="_blank">http://maps.sputnik.ru/?lat=<wbr>37.536410466671626&lng=127.<wbr>00847625732423&zoom=12</a><br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>>>>> name=한국어 and name:ko=한국어 are kind of redudnant, but it is probably<br>
>>>>>> neccessary to help transitioning. Also it is the same way in Japan.<br>
>>>>><br>
>>>>><br>
>>>>> Agree, I hesitated making duplicated data at the first time but I<br>
>>>>> accepted this rule for that reason. It looks like that it is accepted<br>
>>>>> globally. More than half of 20 busiest airports have duplicated name tags.<br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>>>>> ko_rm should actually be renamed in bulk to ko-Latn, possibly in<br>
>>>>>> cooperation and discussion with the japanese community who have the same<br>
>>>>>> problem with ja_rm that should be ja-Latn<br>
>>>>>><br>
>>>>>> See here: <a href="https://wiki.openstreetmap.org/wiki/Names#Localization" rel="noreferrer" target="_blank">https://wiki.openstreetmap.<wbr>org/wiki/Names#Localization</a><br>
>>>>>> the next paragraph in this wiki page is interesting too. We should<br>
>>>>>> avoid transliterations. According to this rule 90% of the name:ko_rm and<br>
>>>>>> name:en tags should go.<br>
>>>>><br>
>>>>><br>
>>>>> I think Romanized name is useful when the name doesn’t have meaning<br>
>>>>> part. If a name doesn’t have meaning part, then there will be no proper<br>
>>>>> translated name, too. In this case, only ko-Latn tag (or ko_rm) holds<br>
>>>>> foreigner friendly characters properly. In this reason, I don’t hesitate to<br>
>>>>> add ko-Latn to administrative units. However, I think Romanization should be<br>
>>>>> avoided if a name has meaning part. (I already expressed my opinion in<br>
>>>>> previous thread, but again…)<br>
>>>>><br>
>>>>> 1) Romanization of Korean is not simple transliteration. It is<br>
>>>>> difficult to guarantee correctness of Romanized name. First principle of<br>
>>>>> Romanization is “Romanization is based on standard Korean pronunciation.”<br>
>>>>> Finding proper pronunciation of Korean words is difficult job even native<br>
>>>>> Koreans. As well as, “Proper names such as personal names and those of<br>
>>>>> companies may continue to be written as they have been previously.” Only<br>
>>>>> owner of the property can give proper Romanized name.<br>
>>>>> See <a href="http://www.korean.go.kr/front_eng/roman/roman_01.do" rel="noreferrer" target="_blank">http://www.korean.go.kr/front_<wbr>eng/roman/roman_01.do</a><br>
>>>>><br>
>>>>> 2) Even it is my personal experiment, translated name is readable<br>
>>>>> than Romanized name. I think it is better to encourage translate rather than<br>
>>>>> Romanize.<br>
>>>>><br>
>>>>><br>
>>>>> 2017-03-04 18:09 GMT+09:00 Max <<a href="mailto:abonnements@revolwear.com">abonnements@revolwear.com</a>>:<br>
>>>>>><br>
>>>>>> On 2017년 03월 04일 09:39, Andrew Errington wrote:<br>
>>>>>>><br>
>>>>>>> I agree that name tagging should be fixed, but I don't agree that we<br>
>>>>>>> have a solution yet.<br>
>>>>>><br>
>>>>>> Indeed<br>
>>>>>><br>
>>>>>>> Firstly, name=* might not be in Korean language. I can give several<br>
>>>>>>> examples where the name of something in Korea (for example, a shop,<br>
>>>>>>> or a<br>
>>>>>>> restaurant) is in Chinese, English, or French. So, I think we should<br>
>>>>>>> not insist that name=* must always be Korean.<br>
>>>>>><br>
>>>>>> Very good point.<br>
>>>>>><br>
>>>>>>> However, it is useful to make a record of the Korean name in<br>
>>>>>>> name:ko=*<br>
>>>>>>> even if it is the same as name=*. The reason for this is so that we<br>
>>>>>>> can<br>
>>>>>>> make a multilingual map.<br>
>>>>>><br>
>>>>>> Agreed<br>
>>>>>><br>
>>>>>>> I agree that if name=* is a combination of "Korean (English)" it<br>
>>>>>>> should<br>
>>>>>>> be changed, but as an English speaker living in Korea it is very<br>
>>>>>>> useful<br>
>>>>>>> for me, so I am reluctant to make that change. And if it's useful<br>
>>>>>>> for<br>
>>>>>>> me, it is probably useful for other people.<br>
>>>>>><br>
>>>>>> While I generally sympathize, I think this is a bit of an colonialzing<br>
>>>>>> view onto Korea. Hell would break loose if someone would think it's<br>
>>>>>> appropriate to tag every item in the states with Korean or Arabic<br>
>>>>>> transcriptions.<br>
>>>>>><br>
>>>>>>> This brings me to another important point, we must think of the<br>
>>>>>>> people<br>
>>>>>>> who will be using the data. We must provide data which is properly<br>
>>>>>>> tagged so that the map renderer can choose the correct tag to label<br>
>>>>>>> every road or street or building for the language chosen by the user.<br>
>>>>>>> I<br>
>>>>>>> think the reason why name=* was a combination of "Korean (English)"<br>
>>>>>>> was<br>
>>>>>>> because we didn't have renderers that could render in different<br>
>>>>>>> languages. Maybe we still don't, but we should be thinking of the<br>
>>>>>>> future, as well as the present.<br>
>>>>>><br>
>>>>>> That's very true. I hope these multilingual renderers will appear<br>
>>>>>> soon, so we have one less reason to slow down the transition.<br>
>>>>>> Maybe an intermediate solution would be to have a Korean render style?<br>
>>>>>> <a href="http://openstreetmap.kr" rel="noreferrer" target="_blank">openstreetmap.kr</a> ? just like the german style at<br>
>>>>>> <a href="https://www.openstreetmap.de/karte.html" rel="noreferrer" target="_blank">https://www.openstreetmap.de/<wbr>karte.html</a><br>
>>>>>><br>
>>>>>>> I think we have to have a full discussion before you run your<br>
>>>>>>> automated<br>
>>>>>>> script. We should also remember that there is no urgency, and we<br>
>>>>>>> should<br>
>>>>>>> not be hasty.<br>
>>>>>><br>
>>>>>><br>
>>>>>> ______________________________<wbr>_________________<br>
>>>>>> Talk-ko mailing list<br>
>>>>>> <a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
>>>>>> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> Talk-ko mailing list<br>
>>>>> <a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
>>>>> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Talk-ko mailing list<br>
>>>> <a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
>>>> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
>>>><br>
>>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Talk-ko mailing list<br>
>> <a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Talk-ko mailing list<br>
> <a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
Talk-ko mailing list<br>
<a href="mailto:Talk-ko@openstreetmap.org">Talk-ko@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ko" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-ko</a><br>
</div></div></blockquote></div><br></div>