OpenStreetMap
I find that OpenStreetMap has the most current and most accurate data for hiking trails. But I also find websites and apps that use OpenStreetMap data like OpenTopoMap and CalTopo take a fairly long time, often months, to update. Some apps, like AllTrails, don’t seem to update their copy of OSM data at all (the OSM attribution by AllTrails is really buried too but that is a separate issue). Other apps like OsmAnd and Maps.me update frequently but either don’t show elevation (Maps.me) or are fairly complex with formatting other than what I like (OsmAnd).
I really like the look of the older (1950s through 1970s) USGS topographic maps that I was raised on. So for hiking I use Avenza Maps and I load in geo-referenced PDF maps that I render myself using publicly available elevation data and OpenStreetMap extracts. This allows me to have a current map I can use offline that looks good to me.
When I am planning on hiking in some far distant place I usually prepare by generating Avenza compatible geo-referenced PDF maps for the area. I start with looking at the area in JOSM with the various OSM compatible aerial imagery. I get a feel for how well the area has been mapped and sometimes make corrections if there is a glaringly obvious mistake or omission. Once I am comfortable with the data in the area I run my map generation scripts.
Next spring I will be trekking through some Himalayan villages in Nepal. My first step in getting ready for this trip was to revise my map generation scripts to handle internationalization. Once I fixed my scripts I realized that about the only names in the area that have Nepali names on them were those along the border. Those seem to be dual named in Nepali and Chinese. My guess is that it is politically expedient to have the name tag for Mount Everest be “珠穆朗玛峰 - सगरमाथा चुचुरो” rather than in only one of the two languages.
Away from the border most places don’t even have name:ne values at all much less have the Nepali name as the value for the name tag. They all seem to be “Romanized” (I did not notice what phonetics were used for the transliteration).
I was under the impression that the name value should be in the local language and in the local character set. Even Kathmandu has its name tag set to “Kathmandu” not “काठमाडौ”. Looking at the OSM Wiki, I see this follows the guidelines for mapping in the Kathmandu Valley and the change that specified this tagging was from over seven years ago.
Odd to me but apparently not unusual. Looking at the wiki pages for localization of the name tag and how some other countries are documented it seems this is not uncommon.
My preferred formatting for a name the local name in the local alphabet with the English name, if different, below. For example:
काठमाडौ
Kathmandu
It looks like my map generation script would need to ignore the name field if a name:ne tag is present. The easiest way to do this is to create a special case that is specific to Nepal. And if I were generate a map for some other country I’d have to special case that too.
I wonder why they decided to use this convention as it seems to make things more difficult for internationalizing maps. Why not just put the local official name value in the name tag?
I think the locals should decide how they map, so I will not try to “correct” their style of name tagging. Especially as there does not seem to be a world wide consensus about what is correct.
Discussion
Comment from SomeoneElse on 13 December 2019 at 11:17
I’m sure you’re already aware, but for the benefit of anyone who isn’t, quite a few online maps take that route already. OSM DE’s deutscher Stil does this, and so does the Cycle Map on openstreetmap.org .
What toolchain are you using for this? It’s quite possible that whatever it is it it’ll support some sort of tag transformation (like OSM Carto does, for example).
You certainly can do tag transformations in OsmAnd, and if you create the maps yourself you’ve essentially got full control over what the offline map looks like. The user interface is still OsmAnd though which is not to everyone’s taste.
Comment from n76 on 13 December 2019 at 15:21
My own. Several years back I was responsible for creating a properly scaled printable ski trail maps for a back country winter recreation area. The map it was replacing was one I created on a drafting table back in the early 1990s. Looking around, it seemed the tool chain associated with OSM was the way to go. So I collected trail GPX data, etc. and added the data that was deemed public to OSM. The non-public data went into a separate local data store. I created some scripts that then took our private data, the OSM data for the area and DEM data to create a series of printable maps. Maps varied based on print size, scale and whether or not they showed our non-public data.
When the government agency I volunteer at asked if the maps were compatible with the app they use for other purposes and that app happened to be Avenza which can use geo-referenced PDF files. So I figured out how to extend the PDF generation in my scripts to support geo-referenced PDF creation.
The tool chain consists of bash scripts to pull OSM and SRTM data from the correct sources based on where I want to have a map. The OSM data is loaded into a postgresql database that has the postgis extensions. Then a python script that generates some location specific OSM formatted data, calls various gdal libraries to generate hill/slope shading and topographic contour lines and uses mapnik to generate an image file, etc.
With that tool chain as a foundation, it was pretty easy for me to create one of my own to create topographic maps styled similar to the older USGS “quads” that I learned to use as a child. One reason for creating my own is the current USGS “quads” are computer generated but use a commercial data source for roads and trails that has pretty poor quality in rural areas. By using OSM data I can get a better quality map and can have an updated map within a day or so depending on if my edits make the daily cut off for the OSM extraction generation done by geofabrik.
With respect to “tag transformation”, I’ve got some postgresql stored functions that do the heavy lifting to take the name, name:en, alt_name, alt_name:en and ele tags to generate the name value used by the mapnik XML.
I actually do use OsmAnd. And I’ve created customized render files for it too. But I don’t know how to do is create foot based contour lines in OsmAnd. I’ve trained myself to be pretty good at working in kilometers for horizontal distances as the search teams I’ve worked with all use UTM for coordinates. But my old American brain has trouble dealing with meters for elevation. Yeah, 3 meters is pretty close to 10 feet but doing a mental conversion in bad weather when you are tired is something you want to avoid.
Since I already had a tool chain for creating printable PDF maps and those maps, once geo-referenced, work well in the app that I am used to using when doing my volunteer work, I prefer to go that way most of the time.
Back to the tag transformation: The issue I was trying to point out is that to create the value for the name string you display, if you can’t rely on the OSM name tag’s value being in the local language you need to know the code for the local language. OSM doesn’t support putting that language code on administrative boundaries and even if it did there are areas with multiple official languages and the on the ground signs could be in one, another, or all of the languages. There is no way for a script to figure that out. In addition, you need to get the desired local language into your postgresql database so you need to adjust the style file used by osm2pgsql for each area you want to support.