I sincerely appreciate all the efforts made to make openstreetmap more accessible to everyone.
I have a quick question and didn’t want to bother anyone on Github, so I’ll ask it here.
When I select a node or note, the sidebar with the information for that node or note is displayed. The coordinates appear in a hyperlink. My native language is Spanish and I have OSM Web configured in Spanish. So far so good, however I would like to know why the decimal point separation is shown using commas (,) and not periods (.).
I understand it’s for cultural use, but if we look at it from a technological point of view, all tools accept coordinates with decimal separators using a period (.) few of them also accept the comma (,).
5.9094810, -75.1352170 and 5,9094810, -75,1352170 are not equal (a csv table wouldn’t work). That’s why the hyperlink only uses periods (.). I understand that it’s either an idiomatic courtesy or a strict grammatical rule. But commas don’t really help if I want to transfer those coordinates to Vespucci or another tool.
I know the osm website perfectly, and I know where the coordinates are and how to share them and what opens or doesn’t open when sharing; I also know that they are in the URL. What I want to explain is that if the sidebar is where I’ll get the information about what I’m seeing in OSM Web, why isn’t the information it provides standard?
P.S. My sincere thanks to everyone who makes openstreetmap web such a great tool.
Hello, as you suspected, the commas are being shown in the Spanish locale for consistency with language norms. There’s some discussion about that here:
In my opinion, there should be a standard. It’s not that my opinion alone should be enough, but I am a regular consumer of geospatial data from various public and private entities in my country. And I must say that I haven’t found any commas (,) in the decimal separator, and why is that? Because a standard for consuming that data is followed. And that standard says that all tools universally accept the period (.) and to a lesser extent (a very small one) the comma (,). The projection, epsg codes, and src may vary, but not the period (.)
In the technical and cartographic context, the absolute standard is the period (.)
In the context of exchange formats (xml, json, kml, csv, wkt,…) the absolute standard is the period (.)
In the context of GIS tools such as QGIS, ArcGIS and databases like PostGIS interpret the period as decimal and the comma as a parameter separator.
Not to mention that almost all languages (Python, JavaScript, SQL) require the period to recognize a float type number.
Perhaps in the effort to please everyone, the goal of providing a correctly formatted coordinate has been lost sight of.
I know that osm web aims to be human-friendly, but coordinates are a special type of data. Unlike a date or currency, the primary purpose of a coordinate on screen is to be transferred to another search or navigation tool. A coordinate that means nothing on its own is useless; instead, it must be combined with a tool that reads it and locates it at that point. A coordinate with commas is useless and must be reformatted. A coordinate on a screen isn’t meant to be memorized; its function is to be copied. Maintaining the decimal point ensures that the data is useful and functional for the user who needs to use that location in another tool; otherwise, they wouldn’t look for it there.
Furthermore, the excuse of “being human-friendly” is quite ambiguous and selective (whether it’s translated or not) and doesn’t apply in this case since the key=value pairs remain in English. If it were truly user-friendly, someone who doesn’t know about tagging or doesn’t speak English should be able to understand what the key=value table refers to. If a user is expected to understand technical terms like highway=track or waterway=river, they can certainly understand the decimal point, which is the global standard for exchanging geospatial data.