# Given latitude/longitude, how to determine whether point is in Japan or China?

For OpenStreetMap names transliteration to Latin characters, I need to know whether a point (latitude, longitude) should be transliterated to Japanese or Chinese.

What formula `f(latitude, longitude)` would tell whether the point is in Japan or China?

It does not need to be perfect, especially since there are islands whose status is disputed.
For transliteration purposes Taiwan is better included in the Chinese-speaking zone.

The goal is actually for the Android app OsmAnd to decide on-the-fly for thousands of labels which language to show, so it must be extremely fast, and must be able to work offline.

• You should check if the point falls into a (simplified) country border polygon. Is there really a reason to use a very rough but little quicker aproach? Dec 13 '13 at 13:35
• @JakubKania: Any approach is fine, feel free to propose an answer :-) Especially if such polygon data is available somewhere under an open source license, that would be an excellent answer! Dec 13 '13 at 13:39
• Of course they are available. OSM has such polygons for every country. See relations with the boundary=administrative tag.
– scai
Dec 13 '13 at 16:41

``````106.38 + longitude - 0.666*latitude
``````
• Positive => Japan
• Negative => China or Taiwan

It is still a bit rough around the tiny islands, but not too bad I think.

• If you can provide details why this works, it would be a better answer. Dec 20 '13 at 14:27
• @DevdattaTengshe: I took 2 points: one point just East of Taitung in Taiwan, and one point just between Sapporo and Vladivostok. Then I calculated the equation of that line. Dec 20 '13 at 14:54

Very rough: Everything with longitude > 130 East is Japanese.

• +1 Thanks! Korea does not use kanji, so it is easy to recognize by just checking the character range :-) Dec 13 '13 at 12:36
• Just a note: 127 is probably a better value as both Harbin (China) and Naha (Japan) are big cities, the largests at the mutual longitudes. Dec 13 '13 at 12:59

If speed is not an issue, and if your app is online, you could use google's reverse geocoding api

• Sorry I forgot to mention that it needs to be extremely fast and must work offline. I edit my question. +1 for great idea otherwise! Dec 20 '13 at 1:24

While others have given you quick and dirty solutions, I would always prefer a more robust solution which provides the correct solution in all cases, and is extendable.