Please, be aware of the real purpose of the name:en key. It is not for Latin transliteration of any kind, it is for names in English (and these are not the same things).
But I need a Solution for our problem not a negative critic.
As you may noticed there are no English road names in Thailand at all.
But in practise most of the Thai roads are using the name:en” tag for the Romanized version of the Thai name.
So what is your solution?
The fact that you need a solution doesn’t give you a right to break the rules of the project. There are a lot of people who want to use OSM for their own purpose. If everyone will do whatever they want, there would be a mess here and nothing else. So, your argumentation is fallacious and actions you are proposing are disrespectful.
If a name can be romanized (transliterated) automatically, it must be done during the data processing before making a map for a navigator, not in the OSM database. Just like it is made for many countries with a non-Latin alphabet on https://www.openstreetmap.de/karte.html That is the right solution that respects rules of this project.
So you suggest to delete all the name:en values of roads in Thailand then? Normally OSM contributors in Thailand (mis)use the name:en to tag the Romanized version of a Thai name. And what about places? The often have name:en values too!
Should we delete all name:en values in Thailand then because it is a «misuse», a «disrespect» of the system and let only map renderer Romanize Thai names?
Theoretically you are right *name:en” is not the appropriate tag for Romanized Thai names – but it is the De Facto Standard here in Thailand.
I think ref values shouldn’t Romanized by automatic renderers.
There is a defined List of a three-letter Latin code of all 77 Thai provinces [here] (https://en.wikipedia.org/wiki/Provinces_of_Thailand) which could be used for a «International» reference instead of a Romanization of the two-letter Thai code.
But how to? How not to break rules? Can we define new rules for tagging Rural Road without breaking «fundamental» OSM rules?
ชบ is the official Thai two-letter code of the province ชลบุรี (Chonburi)
Romanization of ชบ renders ChB (ช=ch, บ=b) (ISO 11940, RTGS, ALA-LC)
Therefore an international reference of ชบ.1095 could be ChB.1095. Problem solved? – Not at all!
จบ is the official Thai two-letter code of the province จันทบุรี (Chanthaburi)
Romanization of จบ renders CB (จ=c, บ=b) (ISO 11940) or ChB (จ=ch, บ=b) (RTGS) or ČhB (จ=čh, บ=b) (ALA-LC).
In the first case all three Romanization got the same result, but not in the second case. Even worse one method renders the same value for Chonburi and Chanthaburi and an other one uses a tonal mark in its representation.
This a clearly «no go» for Romanization.
Instead we should better use the already defined three-letter Latin provincial code like:
ชบ.1095 → CBI.1095 as an international reference
But how to use it? How to implement it smoothly into OSM? How not to offend the OSM hardliners?
If “standard de-facto” contradicts the basic rules, it is a bad standard. Fake “English” names are rubbish. I can’t make anybody to delete it, but not having a rubbish data is better than having it in the database. However, some places (like big cities and towns, well-known outside the country) could actually have names in English or any other language. But not every tiny village or road.
Road numbers are a bit different story. If there is an official (issued by some government authority) list of codes of roads or provinces, that uses Latin letters for the purpose of the internationalization, it is completely correct and acceptable to use int_ref= key to store it. But only if these romanized codes actually exist. If it is just for the purpose of easier conversion for the navigator - that would be wrong.
So, the proper variant with existing codes would be something like that: highway=tertiaryref=ชบ.1095int_ref=CBI.1095 - you don’t really need a separate national reference tag because it is only needed if it is different from the reference number (it happens, for example, if a reference code is assigned by a local authority while national reference - by the government of the whole country).
I want to add, that in this project, there are a lot of “de-facto” things, results of a human factor, mistakes, even unnoticed vandalism. But it doesn’t mean it is good or even normal. Only if we will do our best to improve data quality, we would see a progress here instead of stagnation (or even degradation).
Technically, Wikipedia is not always the best source. This article should have a reference to the original document, law or regulation, where they’ve got this information from. That should be a source for these codes, not Wikipedia itself.
Yes not always – but sometimes Wikipedia is the best source you can get and until no Thai Official corrects the codes in their Thai Wikipedia Entry I will stick with it.
Wikipedia page has not been created by an official person or somebody like that - it was by a regular people. And the rule of Wikipedia is that any information should be taken from a trusted source, so there should be a note, where these codes were taken from (a government website, some document or whatever), and that’s the best source.
I can’t be 100% sure, however, Wikipedia.org is a public international project, not a website of some authority. So, authorities can, probably, publish copies of official documents on Wikipedia, but it can not be used as the only place to publish original information - it will not work in any country by legal reasons because Wikipedia articles can be edited by anybody. So, I don’t really need to read Thai to know how Wikipedia works and how it doesn’t. If you saying that there is a representative of some Thai authority editing this page, then who of these users is that?
And I don’t really understand, why you immediately getting defensive when I’m pointing at your misunderstanding - that is not a good way to improve the quality of what you doing, it’s the way to be left alone with your mistakes.
Obviously, you, being a native Thai speaker, can find an original source of a certain information, or find that there is no such source published online and get it from, for example, a printed text of some law or regulation.
OpenStreetMap
Discussion
Comment from BushmanK on 21 January 2017 at 05:02
Please, be aware of the real purpose of the
name:enkey. It is not for Latin transliteration of any kind, it is for names in English (and these are not the same things).Comment from BushmanK on 21 January 2017 at 08:24
@Balthus★MC, Please, reply here.
The fact that you need a solution doesn’t give you a right to break the rules of the project. There are a lot of people who want to use OSM for their own purpose. If everyone will do whatever they want, there would be a mess here and nothing else. So, your argumentation is fallacious and actions you are proposing are disrespectful.
If a name can be romanized (transliterated) automatically, it must be done during the data processing before making a map for a navigator, not in the OSM database. Just like it is made for many countries with a non-Latin alphabet on https://www.openstreetmap.de/karte.html That is the right solution that respects rules of this project.
Comment from 136154 on 21 January 2017 at 12:33
So you suggest to delete all the name:en values of roads in Thailand then? Normally OSM contributors in Thailand (mis)use the name:en to tag the Romanized version of a Thai name. And what about places? The often have name:en values too!
Should we delete all name:en values in Thailand then because it is a «misuse», a «disrespect» of the system and let only map renderer Romanize Thai names?
Theoretically you are right *name:en” is not the appropriate tag for Romanized Thai names – but it is the De Facto Standard here in Thailand.
I think ref values shouldn’t Romanized by automatic renderers.
The ref tag is a crucial one. These values should be defined – officially defined like in [WikiProject Thailand] (http://wiki.openstreetmap.org/wiki/WikiProject_Thailand) described.
There is a defined List of a three-letter Latin code of all 77 Thai provinces [here] (https://en.wikipedia.org/wiki/Provinces_of_Thailand) which could be used for a «International» reference instead of a Romanization of the two-letter Thai code.
But how to? How not to break rules? Can we define new rules for tagging Rural Road without breaking «fundamental» OSM rules?
Maybe here is a solution: [Key:ref] (http://wiki.openstreetmap.org/wiki/Key:ref) or more specific here: [Key:int_ref] (http://wiki.openstreetmap.org/wiki/Key:int_ref)
Example: highway=tertiary, ref=ชบ.1095
ชบ is the official Thai two-letter code of the province ชลบุรี (Chonburi) Romanization of ชบ renders ChB (ช=ch, บ=b) (ISO 11940, RTGS, ALA-LC)
Therefore an international reference of ชบ.1095 could be ChB.1095. Problem solved? – Not at all!
จบ is the official Thai two-letter code of the province จันทบุรี (Chanthaburi) Romanization of จบ renders CB (จ=c, บ=b) (ISO 11940) or ChB (จ=ch, บ=b) (RTGS) or ČhB (จ=čh, บ=b) (ALA-LC).
In the first case all three Romanization got the same result, but not in the second case. Even worse one method renders the same value for Chonburi and Chanthaburi and an other one uses a tonal mark in its representation.
This a clearly «no go» for Romanization.
Instead we should better use the already defined three-letter Latin provincial code like:
ชบ.1095 → CBI.1095 as an international reference
But how to use it? How to implement it smoothly into OSM? How not to offend the OSM hardliners?
There are several options:
Suggestions?
Comment from BushmanK on 21 January 2017 at 16:01
If “standard de-facto” contradicts the basic rules, it is a bad standard. Fake “English” names are rubbish. I can’t make anybody to delete it, but not having a rubbish data is better than having it in the database. However, some places (like big cities and towns, well-known outside the country) could actually have names in English or any other language. But not every tiny village or road.
Road numbers are a bit different story. If there is an official (issued by some government authority) list of codes of roads or provinces, that uses Latin letters for the purpose of the internationalization, it is completely correct and acceptable to use
int_ref=key to store it. But only if these romanized codes actually exist. If it is just for the purpose of easier conversion for the navigator - that would be wrong.So, the proper variant with existing codes would be something like that:
highway=tertiaryref=ชบ.1095int_ref=CBI.1095- you don’t really need a separate national reference tag because it is only needed if it is different from the reference number (it happens, for example, if a reference code is assigned by a local authority while national reference - by the government of the whole country).Comment from 136154 on 21 January 2017 at 16:56
Okay – thank you for your helpful comment and suggestion.
Comment from BushmanK on 21 January 2017 at 17:06
@Balthus★MC, always welcome.
I want to add, that in this project, there are a lot of “de-facto” things, results of a human factor, mistakes, even unnoticed vandalism. But it doesn’t mean it is good or even normal. Only if we will do our best to improve data quality, we would see a progress here instead of stagnation (or even degradation).
Comment from 136154 on 21 January 2017 at 17:09
Yes, there is an «official» List with a three-letter Latin code for every Thai province, which can be found in Wikipedia:
[https://th.wikipedia.org/wiki/จังหวัดของประเทศไทย] (https://th.wikipedia.org/wiki/จังหวัดของประเทศไทย) (Thai)
Comment from BushmanK on 21 January 2017 at 17:17
Technically, Wikipedia is not always the best source. This article should have a reference to the original document, law or regulation, where they’ve got this information from. That should be a source for these codes, not Wikipedia itself.
Comment from 136154 on 23 January 2017 at 04:39
Yes not always – but sometimes Wikipedia is the best source you can get and until no Thai Official corrects the codes in their Thai Wikipedia Entry I will stick with it.
Comment from BushmanK on 23 January 2017 at 04:46
Wikipedia page has not been created by an official person or somebody like that - it was by a regular people. And the rule of Wikipedia is that any information should be taken from a trusted source, so there should be a note, where these codes were taken from (a government website, some document or whatever), and that’s the best source.
Comment from 136154 on 24 January 2017 at 22:09
How do you know that no «official person» is responsible for the content in this page?
[จังหวัดของประเทศไทย] (https://th.wikipedia.org/wiki/จังหวัดของประเทศไทย)
Can you read Thai?
You can do an internet search by your own with:
จังหวัดของประเทศไทย ตัวย่อ อักษรโรมัน (Provinces of Thailand Abbreviation Roman)
Let me know if you could find a trusty source for the three-letter Latin province code!
Thank you
Comment from BushmanK on 25 January 2017 at 00:48
@Balthus★MC,
I can’t be 100% sure, however, Wikipedia.org is a public international project, not a website of some authority. So, authorities can, probably, publish copies of official documents on Wikipedia, but it can not be used as the only place to publish original information - it will not work in any country by legal reasons because Wikipedia articles can be edited by anybody. So, I don’t really need to read Thai to know how Wikipedia works and how it doesn’t. If you saying that there is a representative of some Thai authority editing this page, then who of these users is that?
And I don’t really understand, why you immediately getting defensive when I’m pointing at your misunderstanding - that is not a good way to improve the quality of what you doing, it’s the way to be left alone with your mistakes.
Obviously, you, being a native Thai speaker, can find an original source of a certain information, or find that there is no such source published online and get it from, for example, a printed text of some law or regulation.