On 22 Feb 2024 20:15:55 GMT, Jolly Roger wrote:

>> I personally don't mind paying a reasonable price for an app but I
>> despise (and won't) rent an app.
>
> Same here.

I would pay for an app if there was no other app that did the job,
but there's always a FOSS app that does the job just fine without paying.

For example, these all allow an unlimited number of saved GPS tracks.
Almost all are open source which is where I get almost all my apps from.

FOSS GPS Logger by BasicAirData 4.3 star 2.37K reviews 100K+ Downloads free adfree
https://play.google.com/store/apps/details?id=eu.basicairdata.graziano.gpslogger

FOSS OpenTracks by Dennis Guse 4.0 star 53 reviews 500+ Downloads free adfree
https://play.google.com/store/apps/details?id=de.dennisguse.opentracks.playstore
https://f-droid.org/en/packages/de.dennisguse.opentracks/
(it's payware on the google play store but open source freeware on F-Droid)

GPSLogger II - AIO by Matthias Marquardt 4.3 star 127 reviews 10K+ Downloads free adfree
https://play.google.com/store/apps/details?id=com.emacberry.gpslogger

FOSS OSMTracker for Android by Laboratorio Experimental 3.8 star 228 reviews 50K+ Downloads free adfree
https://play.google.com/store/apps/details?id=net.osmtracker

Geo Tracker - GPS tracker by Ilya Bogdanovich 4.6 star 88K reviews 5M+ Downloads free adfree inapp purchases
https://play.google.com/store/apps/details?id=com.ilyabogdanovich.geotracker

After I posted that, I ran a better search in the app finder for
a. gps tracking apps
b. that are free
c. without ads
d. and without in-app purchases

Where >75 apps came up, many of which weren't in the prior list,
so I went through the list to list a few others might like to try.

FOSS GPS Logger by BasicAirData 4.3 star 2.37K reviews 100K+ Downloads free adfree
https://play.google.com/store/apps/details?id=eu.basicairdata.graziano.gpslogger

FOSS OpenTracks by Dennis Guse 4.0 star 53 reviews 500+ Downloads free adfree
https://play.google.com/store/apps/details?id=de.dennisguse.opentracks.playstore
https://f-droid.org/en/packages/de.dennisguse.opentracks/
(it's payware on the google play store but open source freeware on F-Droid)

GPSLogger II - AIO by Matthias Marquardt 4.3 star 127 reviews 10K+ Downloads free adfree
https://play.google.com/store/apps/details?id=com.emacberry.gpslogger

FOSS OSMTracker for Android by Laboratorio Experimental 3.8 star 228 reviews 50K+ Downloads free adfree
https://play.google.com/store/apps/details?id=net.osmtracker

Geo Tracker - GPS tracker by Ilya Bogdanovich 4.6 star 88K reviews 5M+ Downloads free adfree inapp purchases
https://play.google.com/store/apps/details?id=com.ilyabogdanovich.geotracker

GPSLogger A lightweight GPS logger, battery efficient, GPX/KML, add notes, share, upload.
https://gpslogger.app/
https://f-droid.org/en/packages/com.mendhak.gpslogger/
https://github.com/mendhak/gpslogger

LD-Log Lite - GPS Logger by A.Wedemeyer - Outdoor & Sailing Apps 4.4 star 231 reviews 10K+ Downloads
https://play.google.com/store/apps/details?id=com.aw.ldlogFree

Wadlbeisser by Marco Pfattner 4.6 star 778 reviews 50K+ Downloads
https://play.google.com/store/apps/details?id=de.pfattner.speedo.android

Trailblazer by Andrew and Derek 4.7 star 7 reviews 100+ Downloads
https://play.google.com/store/apps/details?id=com.andrewandderek.trailblazer

GPSToolbox by Beijing Tele Industry Information Technology Ltd. 1K+ Downloads
https://play.google.com/store/apps/details?id=net.gotele.gpsbox

OSC - Hiking, Running, Cycling by Eliakim Schuenemann 1K+ Downloads
https://play.google.com/store/apps/details?id=com.eschuenemann.outdoorsportscompanion

Earth Explorer by software1001developer 50+ Downloads
https://play.google.com/store/apps/details?id=com.earth.explorer

Sondel-Buddy pro - Tool for m by Django's Android Apps 100+ Downloads
https://play.google.com/store/apps/details?id=com.DjangoLaunchpad.Sondel_Buddy

Here's a free ad free inapp free app for SPEAKING GPS directions (when walking).
Trail Guide by Jordi Boixadera Planas 3.2 star 13 reviews 1K+ Downloads
https://play.google.com/store/apps/details?id=com.jordiboixadera.trailGuide

And here's a free ad free inapp free app for DRAWING & EDITING GPS tracks
GPXLAB - The GPS Track Editor by LCX Ventures Ltd 4.1 star 8 reviews 100+ Downloads
https://play.google.com/store/apps/details?id=com.lcxventures.gpxlab.app

I've installed all of these and will test them out, but the nature of
gps logging apps while in the field is that it will take me some time.

On Sat, 24th Feb 2024 22:30:48 -0500, Sten deJoode wrote:

> After I posted that, I ran a better search in the app finder for
> a. gps tracking apps
> b. that are free
> c. without ads
> d. and without in-app purchases

Coming from a GIS background I use the free open source QField program
for logging tracks:

https://docs.qfield.org/how-to/tracking
https://github.com/opengisch/QField

Apart from this, OSMAnd can also be set for track logging via plugin:

https://osmand.net/docs/user/plugins/trip-recording

The GooglePlay store carries the OSMAnd+ variant, which is meant to
raise funding for the project and therefore does not match all your
criteria from above. The F-Droid store, OTOH, provides the OSMAnd~
variant, which is also current and feature-identical, just without
the payment-inducing ones. GooglePlay also has a free version (just
named OSMAnd); but this version has some less features compared to
OSMAnd+ and OSMAnd~.

https://f-droid.org/de/packages/net.osmand.plus

Having said this: The OSMAnd project /is/ worth supporting. One-time
payment of 30$ or 30€ will get you lifetime unlimited maps and the
like in OSMAnd+ (and not only in OSMAnd~), as well:

https://osmand.net/docs/user/purchases/android

Bernd

Bernd Rose wrote:

> Coming from a GIS background I use the free open source QField program
> for logging tracks:

That's a great program, it seems, which I was entirely unaware of!

https://github.com/opengisch/QField/releases/tag/v3.1.9Name: qfield-v3.1.9-windows-x64.exe
Size: 60823204 bytes (58 MiB)
SHA256: 1A3B8C5B1AD64FC3CF8CBB7CA848BF5EDCED7EBAC7694634346B37B43A5972EA

QField for QGIS by OPENGIS.ch 4.4 star 6.19K reviews 500K+ Downloads
https://play.google.com/store/apps/details?id=ch.opengis.qfield

https://github.com/opengisch/QField/releases/download/v3.1.9/qfield-v3.1.9-arm64-android.apk
Name: qfield-v3.1.9-arm64-android.apk
Size: 84456352 bytes (80 MiB)
SHA256: D8D1548F5892DC9E52180B28C3C0009F29047467D84B736F7B23A10ADB26BC53

> https://docs.qfield.org/how-to/tracking
> https://github.com/opengisch/QField

Thanks for that information as I generally draw my own backcountry tracks
on caltopo freeware and then convert (if necessary) with gpsbabel freeware
and I stitch geospatial PDFs with either QGis or OziExplorer freeware.
https://play.google.com/store/apps/details?id=com.caltopo.android
https://caltopo.com/map.html#ll=40,-100&z=5&b=mbt
https://qgis.org/en/site/forusers/download.html
http://www.oziexplorer.com/
https://www.gpsbabel.org/

Sometimes I use OpenOrienteering Mapper for basic map-creation tasks.
https://www.openorienteering.org/apps/mapper/
https://github.com/OpenOrienteering/mapper
https://github.com/OpenOrienteering/mapper/releases/download/v0.9.5/OpenOrienteering-Mapper-0.9.5-Windows-x64.exe
https://github.com/OpenOrienteering/mapper/releases/download/v0.9.5/OpenOrienteering-Mapper-0.9.5-Android-arm64-v8a.apk

Where I'm always looking for an easy way to draw a track.
https://play.google.com/store/apps/details?id=com.wolfgangknecht.sketchatrack

But I've always pined for a better way to hike the drawn track
with directions saying "Head west 100 feet to get back on track".
https://play.google.com/store/apps/details?id=com.keuwl.gpswaypoints

> Apart from this, OSMAnd can also be set for track logging via plugin:
> https://osmand.net/docs/user/plugins/trip-recording

The problem with OSMand is their free topographical maps for the USA
are far and away vastly inferior to those of the USGS geospatial PDFs.
https://ngmdb.usgs.gov/topoview/

> The GooglePlay store carries the OSMAnd+ variant, which is meant to
> raise funding for the project and therefore does not match all your
> criteria from above. The F-Droid store, OTOH, provides the OSMAnd~
> variant, which is also current and feature-identical, just without
> the payment-inducing ones. GooglePlay also has a free version (just
> named OSMAnd); but this version has some less features compared to
> OSMAnd+ and OSMAnd~.
> https://f-droid.org/de/packages/net.osmand.plus
> Having said this: The OSMAnd project /is/ worth supporting. One-time
> payment of 30$ or 30� will get you lifetime unlimited maps and the
> like in OSMAnd+ (and not only in OSMAnd~), as well:
> https://osmand.net/docs/user/purchases/android

While OSMAnd~ can save tracks, the maps themselves are vastly inferior
to the USGS PDFs which can be loaded into Avenza or into PaperMaps.
https://play.google.com/store/apps/details?id=com.Avenza
https://www.avenza.com/avenza-maps/
https://play.google.com/store/apps/details?id=ca.abbro.androidmap
https://www.paper-maps.com/

May I ask which of all teh programs above you prefer for two tasks:
1. Drawing a desired track onto a map (to later hike in the wild)
2. Following that drawn track (while hiking in the wild in real time)

Those are the two tasks that I haven't found a great program for.
Which free programs would you recommend for those two critical tasks?

On Sun, 25th Feb 2024 04:34:35 -0500, Sten deJoode wrote:

> The problem with OSMand is their free topographical maps for the USA
> are far and away vastly inferior to those of the USGS geospatial PDFs.
> https://ngmdb.usgs.gov/topoview/

Being a community driven project OSM obviously just needs more contribution
of users from US. Year after year I hear people from US complaining about
the poor quality of OSM maps compared to the professional US Topo ones. If
people don't get a move on, eventually, this situation will never change.
In Europe (and especially so in Germany) OSM maps are often more detailed
and especially more current than (usually really good) official/professional
topo maps.

> May I ask which of all teh programs above you prefer for two tasks:
> 1. Drawing a desired track onto a map (to later hike in the wild)
> 2. Following that drawn track (while hiking in the wild in real time)

With car, bike and the like I don't use track-driven navigation, at all.
In such cases I usually use OSMAnd destination driven navigation with
dynamic route adjustments. On hiking I don't use tracks as targeting
basis, either. In this case I "navigate" map driven (for instance with
QField or "old" paper maps): Every next step is determined by my current
position, the topographical elements drawn for the surrounding area and
in the general direction of major intermediate or final destination points,
and (primarily) on the conditions of my surroundings. (If you come across
a woodland area with recent or even current logging, for instance, you
are usually far better off circumventing it, rather than following the
"usual" track right through it. Afterwards, it often makes no sense to
revert back to the original track. So I often choose a new route that
is more or less parallel to the original one. Any pre-created track would
be useless from this moment on...)

/If/ I would use pre-created tracks for navigation I'd probably create
them as polyline features with whatever GIS program was at hands (like
QGIS or QField).

Bernd
F-Up set to sgs-n

Bernd Rose <b.rose.tmpbox@arcor.de> wrote:
> On Sun, 25th Feb 2024 04:34:35 -0500, Sten deJoode wrote:
>
> > The problem with OSMand is their free topographical maps for the USA
> > are far and away vastly inferior to those of the USGS geospatial PDFs.
> > https://ngmdb.usgs.gov/topoview/
>
> Being a community driven project OSM obviously just needs more contribution
> of users from US. Year after year I hear people from US complaining about
> the poor quality of OSM maps compared to the professional US Topo ones. If
> people don't get a move on, eventually, this situation will never change.
> In Europe (and especially so in Germany) OSM maps are often more detailed
> and especially more current than (usually really good) official/professional
> topo maps.

This indeed seems to be a US-only/mainly problem. OSM maps - at least
the versions in OsmAnd+ - are nearly always more up-to-date than
official/professional maps like TomTom, HERE/NAVTEQ, Google, etc.. At
least that has been my experience in The Netherlands, Germany, Austria
and (especially) Australia.

[...]

On 25 Feb 2024 14:33:10 GMT, Frank Slootweg wrote:

>> In Europe (and especially so in Germany) OSM maps are often more detailed
>> and especially more current than (usually really good) official/professional
>> topo maps.
>
> This indeed seems to be a US-only/mainly problem. OSM maps - at least
> the versions in OsmAnd+ - are nearly always more up-to-date than
> official/professional maps like TomTom, HERE/NAVTEQ, Google, etc.. At
> least that has been my experience in The Netherlands, Germany, Austria
> and (especially) Australia.

It should be noted I am aware of the pondal discrepancy, which is why I
mentioned the free USA USGS topographic maps, which cover every square inch
of the USA in such exquisite detail that they're 50MB for each quadrangle.
https://ngmdb.usgs.gov/topoview/

It should be noted they're not actually "free" in so much as tax dollars
go into making these maps and improving their detail year after year which
makes them different (better) than OSM maps but it doesn't make OSM bad.

In addition, USGS maps are all geopdfs so they stitch together nicely which
makes printing on an standard home printer feasible for larger maps (using
the Adobe PDF printer tiling capabilities or Posterazor for more features).
https://sourceforge.net/projects/posterazor/

I love the idea and implementation of OSMAnd~ and I do not think the Open
Street Maps topo maps are bad, per se - but that the USGS maps are great.
There's absolutely no way to compare them in terms of detail & accuracy.

Of course, if you live in a flat area like the eastern part of Ukraine,
then both maps are fine in that the topographic detail is constant.
Even the terrible Google topographic maps work well in flat terrain.

But in mountainous areas, there is nothing wrong with the OSM maps other
than the USGS maps put them to shame as easily seen with your own eyes.

Let's first pick a location to compare OSM topos with USGS topo maps.
https://en.wikipedia.org/wiki/Mount_Washington

https://ngmdb.usgs.gov/topoview/viewer/#
Search by location: 44�16'13.8"N 71�18'11.7"W
https://ngmdb.usgs.gov/topoview/viewer/#15/44.2676/-71.3039
The first difference is USGS maps go way back to the 1800s where
it's nice to hike those old maps to unearth historical foundations.

Now let's go to the same location on the venerable Open Street Maps.
https://www.openstreetmap.org/#map=5/38.007/-95.844
Search by location: 44�16'13.8"N 71�18'11.7"W
https://www.openstreetmap.org/search?query=44%C2%B016%2713.8%22N%2071%C2%B018%2711.7%22W#map=15/44.2697/-71.2992
That stinks so let's turn on the topographical layers which
seem to be called "Tracetrack Topo" layers (did I do it right?).
https://www.openstreetmap.org/search?query=44%C2%B016%2713.8%22N%2071%C2%B018%2711.7%22W#map=17/44.26986/-71.30282&layers=P

Actually, for Mount Washington (a well-known feature), the discrepancies
aren't all that bad, if I do say so myself. They're not too far off.
https://i.postimg.cc/NftMfvvL/usgs-mtwash-topo.jpg
https://i.postimg.cc/ydfJ3fm2/osm-mtwash-topo.jpg

There is a download button for the USGS maps which nets you a
variety of formats from JPEG (8MB), GeoTiff (20MB), KMZ (5MB) & GeoPDF
(58MB) for the 2021 1:24K "Mount Washington, NH" quadrangle.

Elsewhere you can create your own maps much like you can do a Google
Takeout, where they will send you a 7-day expiry link to download the
custom USGS topographical map of any desired sized (but like a Google
Takeout, they're astoundingly huge).

The Open Street Map also has an export option with many choices.
https://www.openstreetmap.org/export#map=16/44.2684/-71.3024&layers=P
With links to other ways to download the offline OSM topographical maps.
https://download.geofabrik.de/
https://planet.openstreetmap.org/
https://overpass-api.de/api/map?bbox=-71.3156,44.2611,-71.2892,44.2757
https://wiki.openstreetmap.org/wiki/Downloading_data

Overall I was pleasantly surprised at how similar the two were
for this well-known feature (the tallest point in the east coast).

But my experience on the local terrain is that the USA OSM topo
maps are decidedly inferior to the USGS topographical maps.

Mostly what I do is at home, I draw a desired track which is where
the detail is needed the most - while you're sitting in your chair.

Then, outdoors, while it's almost impossible to follow any track
given there are no trails and the forest and cliffs and swamps
get in the way, I try to stick to that desired route as much as
is possible.

Which is why if anyone knows of better on-the-ground off-trail
routing software (ie "Head North 400 feet to get back on track"),
it would be a boon to those who hike hefty terrain where there
are no trails (other than game trails, which often isocline).

Sten deJoode wrote on 25.02.2024 17:32:

> Which is why if anyone knows of better on-the-ground off-trail
> routing software (ie "Head North 400 feet to get back on track"),
> it would be a boon to those who hike hefty terrain where there
> are no trails (other than game trails, which often isocline).

I would love to find an Android app which does that as I've heard of
Android apps that speak the distance & bearing to a waypoint on the route.

Speaking is useful because you are often on your hands and knees, or you
are in a swamp, or rappelling down a steep incline, or otherwise busy.

Or it's raining and your phone is in a plastic ziplock bag, or
even if it's good weather, your hands are busy so the phone is
zippered in a pocket so that it doesn't fall out as you hop streams.

When you do pull out the phone, say when you're on your hands and knees in
a thicket, where your visibility is nearly zero, it's also nice to have a
fat bearing arrow with distance displayed so you know which way to crawl.

A search shows up these which say they do voice walking instructions.
<https://play.google.com/store/apps/details?id=com.jordiboixadera.trailGuide>
<https://play.google.com/store/apps/details?id=app.organicmaps>
<https://play.google.com/store/apps/details?id=com.generalmagic.magicearth>

This one is voice activated so you can control the app without hands.
<https://play.google.com/store/apps/details?id=de.flosdorf.routenavigation

In the search I accidentally found this app which will ring an audible
alarm if you happen to accidentally enter a restricted area like Area 52.
<https://play.google.com/store/apps/details?id=com.technomadapps.gpsalarm>

On Sun, 25th Feb 2024 12:32:03 -0500, Sten deJoode wrote:

> But in mountainous areas, there is nothing wrong with the OSM maps other
> than the USGS maps put them to shame as easily seen with your own eyes.

It probably has more to do with discrepancies between visual styles of
map rendering than with actual wrong or missing items in OSM map data.
OSM carries too much information to be shown at the same time. Therefore,
a myriad of map visualization styles exist for OSM. They not only differ
in the map elements selected for display, but also in attribution of map
features, and the like. If no existing style shows everything as expected,
it is always possible to create a new style with a special selection of
features, attribution and so on.

With OSMAnd, a couple of default map styles are supported. Choose the
one most suitable to your needs. For hiking "Touring view" and "Offroad"
are good choices:

https://osmand.net/docs/user/map/vector-maps/#default-map-styles

> Then, outdoors, while it's almost impossible to follow any track
> given there are no trails and the forest and cliffs and swamps
> get in the way, I try to stick to that desired route as much as
> is possible.

Hiking trails can often be downloaded from specialized portals, like
Waymarked Trails, if you do not want to create them step by step,
yourself:

https://hiking.waymarkedtrails.org/#route?id=5729371&type=relation

> Which is why if anyone knows of better on-the-ground off-trail
> routing software (ie "Head North 400 feet to get back on track"),
> it would be a boon to those who hike hefty terrain where there
> are no trails (other than game trails, which often isocline).

After loading a track into OSMAnd for navigation you have several
methods for further adjustments:

https://osmand.net/docs/user/navigation/setup/gpx-navigation/

If you tell OSMAnd to navigate by track, you'll be able to set up normal
voice navigation as well as navigation by beep tones:

https://osmand.net/docs/user/navigation/guidance/voice-navigation/#beep-modes

HTH
Bernd

On Sun, 25 Feb 2024 23:12:18 +0100, Bernd Rose wrote:

>> But in mountainous areas, there is nothing wrong with the OSM maps other
>> than the USGS maps put them to shame as easily seen with your own eyes.
>
> It probably has more to do with discrepancies between visual styles of
> map rendering than with actual wrong or missing items in OSM map data.

Can you please take a look at this comparison of where I typically hike?
https://i.postimg.cc/nV0Ttps6/osm-vs-usgs.jpg

I wonder if the "visual style" is the reason the OSM topo maps stink in the
USA compared to the USGS topo maps - or if it's simply the lack of data.
The USGS has been gathering surveying data since the 1800s.
They're well funded.

Where does OSM get their topographic information?

Hopefully not from Google as Google's publicly available topo maps are
horrid in terms of lack of elevation detail.

> OSM carries too much information to be shown at the same time. Therefore,
> a myriad of map visualization styles exist for OSM. They not only differ
> in the map elements selected for display, but also in attribution of map
> features, and the like. If no existing style shows everything as expected,
> it is always possible to create a new style with a special selection of
> features, attribution and so on.
> With OSMAnd, a couple of default map styles are supported. Choose the
> one most suitable to your needs. For hiking "Touring view" and "Offroad"
> are good choices:
> https://osmand.net/docs/user/map/vector-maps/#default-map-styles

Neither of those "sound" useful for an area that has no trails or paths.
The only trails are game trails. Gullies. Cliffs. Swamps. Creeks. etc.

Since I gave up on using OSM maps on the phone for backcountry hiking, can
you tell me what "style" I would use simply to get the best topography?

>> Then, outdoors, while it's almost impossible to follow any track
>> given there are no trails and the forest and cliffs and swamps
>> get in the way, I try to stick to that desired route as much as
>> is possible.
>
> Hiking trails can often be downloaded from specialized portals, like
> Waymarked Trails, if you do not want to create them step by step,
> yourself:
> https://hiking.waymarkedtrails.org/#route?id=5729371&type=relation

While I'm sure most people follow established trails, I shun them.
I pick a point on another ridge a mile LOS away and head toward it.

Since there are cliffs involved, I bring a few hundred feet of rope.
I've found the OSM topo maps almost completely useless for that purpose.

OSM is completely lacking in necessary detail that the USGS maps have.
I wish it weren't so.

Look at this comparison of the same area that I often hike in.
https://i.postimg.cc/nV0Ttps6/osm-vs-usgs.jpg

There's no comparison.
The OSM topo map stinks compared to the USGS map.

Unless there's some kind of "detail" that I need to turn on for the OSM?
>> Which is why if anyone knows of better on-the-ground off-trail
>> routing software (ie "Head North 400 feet to get back on track"),
>> it would be a boon to those who hike hefty terrain where there
>> are no trails (other than game trails, which often isocline).
>
> After loading a track into OSMAnd for navigation you have several
> methods for further adjustments:
> https://osmand.net/docs/user/navigation/setup/gpx-navigation/
> If you tell OSMAnd to navigate by track, you'll be able to set up normal
> voice navigation as well as navigation by beep tones:
> https://osmand.net/docs/user/navigation/guidance/voice-navigation/#beep-modes

This does work. Thanks. What I need is for it to work on the USGS maps.

On Mon, 26th Feb 2024 17:11:35 -0500, Sten deJoode wrote:

> Where does OSM get their topographic information?
>
> Hopefully not from Google as Google's publicly available topo maps are
> horrid in terms of lack of elevation detail.

Google topography is commercial and therefore cannot be used as a source
for OSM. (Which needs to be royalty free.) Sources can either be new data
freely donated by individuals/companies/... who created it, themselves.
Or it can be data, that either never carried a restrictive copyright or
ran out of it, already:

https://wiki.openstreetmap.org/wiki/Potential_datasources

With "topographic information" you mainly seem to refer to the natural
part of the topography. And in this mainly contour lines and hydrographic
soil data.

The OSM project concentrates on the artificial/cultural aspects of the
topography (streets, buildings, names, and the like). To create maps
containing natural topographic background information from the geographic
OSM data, there's some low-res data available. Users and applications
that need more detailed natural topography include it from other sources.

Reasoning behind this is concentration on geographic data, that can be
easily reviewed (and if necessary: corrected) by the participants of the
OSM project.

Contour lines, soil and hydrography data and the like are, OTOH, especially
suited for a combination of remote sensing and modeling or need inventory
by specialists (often with tailored equipment and very specific laboratory
analyses, for instance for soil and aquiver mapping).

Contour lines with high resolution, for instance, can be easily calculated
from high-res DTM data. If the latter is freely available (nowadays usually
from airborne laser scanning with meter or submeter resolution), it is
just a matter of computing power and/or time to create the former. Here
in Europe free availability of this data is not a problem. I can't assess
the availability in the US, though. Shuttle Radar Topography Mission (SRTM)
is globally available, but just with resolution of 30 meters, which isn't
too great.

Programs like OSMAnd usually combine selected and attributed data excerpts
from the central OSM database with contour lines from another source. If
you get higher resolution contour lines from a better source for your area
you can use it to overwrite the standard set. Be aware though, that high-res
contour line vector data may require quite some computing power to render
on-the-fly.

For the US, TopOSM may be a good source for OSM based maps with enriched
natural topography:

https://wiki.openstreetmap.org/wiki/TopOSM

It seems to be an ongoing project, though. So you might be well-advised to
confer with them directly.

>> https://osmand.net/docs/user/map/vector-maps/#default-map-styles
>
> Neither of those "sound" useful for an area that has no trails or paths.
> The only trails are game trails. Gullies. Cliffs. Swamps. Creeks. etc.
>
[...]
>> Hiking trails can often be downloaded from specialized portals, like
>> Waymarked Trails, if you do not want to create them step by step,
>> yourself:
>> https://hiking.waymarkedtrails.org/#route?id=5729371&type=relation
>
> While I'm sure most people follow established trails, I shun them.
> I pick a point on another ridge a mile LOS away and head toward it.

If this was the case, you'd have no use for a program explicitly created
for the navigation along artificial lines, like OSMAnd. In the scenario
you described first, OTOH, you wanted to follow a pre-defined track. (It
doesn't matter that this track would be hand-drawn by yourself and would
perhaps not follow any real lane or trail.) And you wanted to get routing
information whenever you leave this track (too much) or whenever you have
to take a major turn of direction. If you still want to go this way, but
find no source for better suited contour lines for your area, you may
need to use a two-fold approach: Use OSMAnd for navigation commands along
your predefined track and use another program for the visualization of
your current position on (raster) USGS topo maps. If you just rove the
wild with a rough idea of direction and target, you can forgo navigation
completely...

Bernd

On Tue, 27 Feb 2024 18:57:31 +0100, Bernd Rose wrote:

> Sources can either be new data
> freely donated by individuals/companies/... who created it, themselves.
> Or it can be data, that either never carried a restrictive copyright or
> ran out of it, already:
> https://wiki.openstreetmap.org/wiki/Potential_datasources

Don't get me wrong. I'm not deprecating open source maps at all. In fact, I
absolutely love the concept of open maps. That open source concept works
well for roads, which are easy to add to the open source maps but the OSM
implementation is atrocious for topographic maps (unfortunately).

I think you don't notice how terrible the OSM topographic maps are because
you have nothing better to compare them to outside of the United States.

In the United States, we already have "open" isocline maps by the USGS.
Once you use the USGS maps for real-world off-trail hiking, you'll cry if
you have to resort to the low-resolution low-detail inaccurate OSM maps.

To help you see the delta, I zoomed into the area I previously provided:
https://i.postimg.cc/nV0Ttps6/osm-vs-usgs.jpg

And then I drew a line of the same size on both maps from two known points.
https://i.postimg.cc/bYtQgB42/test1-usgs-vs-osm.jpg

To help you, I changed HSV values to make the isoclines stand out better.
https://i.postimg.cc/4yP4wZGg/test1-usgs-vs-osm-colorized.jpg

Can you please take a look at those comparisons and let me know if you're
also seeing the huge discrepancies that I'm seeing in isocline lines?

>> Hopefully not from Google as Google's publicly available topo maps are
>> horrid in terms of lack of elevation detail.
>
> Google topography is commercial and therefore cannot be used as a source
> for OSM. (Which needs to be royalty free.)

Understood. My point was that the Google topography available in their
normal web page is terrible, although the Google Earth topographic maps are
maybe better (they look like USGS maps wrapped around a globe but it has
been a very long time since I added the USGS maps to Google Earth).

> With "topographic information" you mainly seem to refer to the natural
> part of the topography. And in this mainly contour lines and hydrographic
> soil data.

You are correct that I am referring to what I need to know when I'm hiking.
Boots on the ground.

I need to know cliffs. Gullies. Ravines. Gulches. Steep slopes. Hogsbacks.
Ridges. Of course roads & structures also are nice to have on those maps.

> The OSM project concentrates on the artificial/cultural aspects of the
> topography (streets, buildings, names, and the like). To create maps
> containing natural topographic background information from the geographic
> OSM data, there's some low-res data available. Users and applications
> that need more detailed natural topography include it from other sources.

That then is probably the reason why OSM topographic maps suck so bad.
Do you see the difference in the zoomed-in section I showed you above?

The OSM maps are not only inaccurate but they're missing most great detail.

> Reasoning behind this is concentration on geographic data, that can be
> easily reviewed (and if necessary: corrected) by the participants of the
> OSM project.
>
> Contour lines, soil and hydrography data and the like are, OTOH, especially
> suited for a combination of remote sensing and modeling or need inventory
> by specialists (often with tailored equipment and very specific laboratory
> analyses, for instance for soil and aquiver mapping).
>
> Contour lines with high resolution, for instance, can be easily calculated
> from high-res DTM data. If the latter is freely available (nowadays usually
> from airborne laser scanning with meter or submeter resolution), it is
> just a matter of computing power and/or time to create the former. Here
> in Europe free availability of this data is not a problem. I can't assess
> the availability in the US, though. Shuttle Radar Topography Mission (SRTM)
> is globally available, but just with resolution of 30 meters, which isn't
> too great.
>
> Programs like OSMAnd usually combine selected and attributed data excerpts
> from the central OSM database with contour lines from another source. If
> you get higher resolution contour lines from a better source for your area
> you can use it to overwrite the standard set. Be aware though, that high-res
> contour line vector data may require quite some computing power to render
> on-the-fly.
>
> For the US, TopOSM may be a good source for OSM based maps with enriched
> natural topography:
> https://wiki.openstreetmap.org/wiki/TopOSM
> It seems to be an ongoing project, though. So you might be well-advised to
> confer with them directly.

Thank you for that information, which is new to me, and which discusses the
granularity when they say "Hillshading and contour lines are derived from
the 1/3 arc-second National Elevation Dataset from USGS."
https://www.usgs.gov/search?keywords=Elevation

I generally use the 1:24K maps for backcountry off-road off-trail hiking,
where I have to look up what it means to be using 1/3 arc-second data.
<https://data.usgs.gov/datacatalog/data/USGS:3a81321b-c153-416f-98b7-cc8e5f0e17c3>

That implies about 10 meter resolution, but I'm not sure how that compares
to the USGS 1:24000 maps that I habitually load into PaperMaps on Android.
https://www.nwcg.gov/course/ffm/mapping/52-map-scale

I didn't know about that project as I had already long ago given up on the
existing OSM topographic maps, but I always wondered why almost all people
didn't seem to understand when I said the OSM topo maps are atrocious.

I think they don't know how great the USA USGS topographic maps are, so
they don't know enough to assess how terrible the OSM topographic maps are.
https://i.postimg.cc/4yP4wZGg/test1-usgs-vs-osm-colorized.jpg

Looking at the Wiki for TopOSM you referenced, the first thing I noticed is
they use the USGS map data, so that's a good sign in terms of accuracy.
https://www.usgs.gov/faqs/what-types-elevation-datasets-are-available-what-formats-do-they-come-and-where-can-i-download

I appreciate you pointed that effort out as it seems the way they differ
from the source USGS topographic data is they strive to *present* the maps
in a "more pleasing" way - which is fine by me as

Unfortunately, when I tried to download the OSM 1/3rd arc-second maps from
the wiki page referenced, they all came up with a 404 not found error.

>> While I'm sure most people follow established trails, I shun them.
>> I pick a point on another ridge a mile LOS away and head toward it.
>
> If this was the case, you'd have no use for a program explicitly created
> for the navigation along artificial lines, like OSMAnd. In the scenario
> you described first, OTOH, you wanted to follow a pre-defined track. (It
> doesn't matter that this track would be hand-drawn by yourself and would
> perhaps not follow any real lane or trail.) And you wanted to get routing
> information whenever you leave this track (too much) or whenever you have
> to take a major turn of direction. If you still want to go this way, but
> find no source for better suited contour lines for your area, you may
> need to use a two-fold approach: Use OSMAnd for navigation commands along
> your predefined track and use another program for the visualization of
> your current position on (raster) USGS topo maps. If you just rove the
> wild with a rough idea of direction and target, you can forgo navigation
> completely...

You are astute in that most of backcountry navigation is dead reckoning,
but often you're deep in a gully or on your hands and knees in a thicket,
where dead reckoning is much harder due to lack of farfield visual cues.

Also just physically staying on a brushy hogsback seems so easy when you
look at the problem set on a map, but inevitable small errors tend to
multiply such that you'll be on the wrong side of that hogsback within
minutes if you're not constantly following the previously drawn track.

The drawn track is especially important when you're aiming to cross ridges
at an optimal cleft, since once you aim downhill at the wrong spot, the
terrain quickly becomes almost impossible to traverse in a matter of feet.

About the only time you go in a straight line is when you're rappelling.

Anyway, I appreciate the advice and the new information from you that the
OSM topographic maps are based on the USGS 1/3rd arc-second USA data.

May I ask for you to give me advice on two questions that are still open?

1. Do you see the huge difference that I see in these two zooms?
https://i.postimg.cc/bYtQgB42/test1-usgs-vs-osm.jpg
https://i.postimg.cc/4yP4wZGg/test1-usgs-vs-osm-colorized.jpg

The reason I ask is I hear from everyone how useful the OSM topo maps
are & yet, when I use them, I find them lacking in almost every way.

(But I had not known about the 1/3 arc-second OSMTopo maps, which I
don't have yet - but which I will search to find a source of today.)

On Tue, 27 Feb 2024 15:56:14 -0500, Sten deJoode wrote:

> I think you don't notice how terrible the OSM topographic maps are because
> you have nothing better to compare them to outside of the United States.

Our topographical maps (official as well as OSM) hereabouts are good enough
to notice few discrepancies in comparison to sub-meter level laserscan DTM.
Currently, some of our official (digital) land parcel maps - depicting the
ownership of the land - are less accurate when doing in-depth analysis of
all available sources. Non-essential topographical borders out in the woods
and fields are usually correct in the sub 5 meter range. That's <0.2 mm on
your USGS topo map...

>> With "topographic information" you mainly seem to refer to the natural
>> part of the topography. And in this mainly contour lines and hydrographic
>> soil data.
>
> You are correct that I am referring to what I need to know when I'm hiking.
> Boots on the ground.

Walking trails is /also/ "boots on the ground". The trail would be part of
the OSM vector data, though, because it is either artificially created or
else identified by someone as relevant for connecting 2 points.
> I need to know cliffs. Gullies. Ravines. Gulches. Steep slopes. Hogsbacks.
> Ridges. Of course roads & structures also are nice to have on those maps.

Yes. And if you US citizens would do your homework in the OSM community,
they would have been included in the OSM data for years. The topographical
elements you listed are mappable as (single) objects by the community.
They do not have the character of contour lines, which are better acquired
from remote sensing data.
>> The OSM project concentrates on the artificial/cultural aspects of the
>> topography (streets, buildings, names, and the like). To create maps
>> containing natural topographic background information from the geographic
>> OSM data, there's some low-res data available. Users and applications
>> that need more detailed natural topography include it from other sources.
>
> That then is probably the reason why OSM topographic maps suck so bad.
> Do you see the difference in the zoomed-in section I showed you above?

Why should I watch your sorry US-excuse for doing nothing? I will not cross
the sea just to do your mapping tasks for you.

Bernd

Bernd Rose wrote:

> On Tue, 27 Feb 2024 15:56:14 -0500, Sten deJoode wrote:
>
>> I think you don't notice how terrible the OSM topographic maps are because
>> you have nothing better to compare them to outside of the United States.
>
> Our topographical maps (official as well as OSM) hereabouts are good enough
> to notice few discrepancies in comparison to sub-meter level laserscan DTM.
> Currently, some of our official (digital) land parcel maps - depicting the
> ownership of the land - are less accurate when doing in-depth analysis of
> all available sources. Non-essential topographical borders out in the woods
> and fields are usually correct in the sub 5 meter range. That's <0.2 mm on
> your USGS topo map...
>
>>> With "topographic information" you mainly seem to refer to the natural
>>> part of the topography. And in this mainly contour lines and hydrographic
>>> soil data.
>>
>> You are correct that I am referring to what I need to know when I'm hiking.
>> Boots on the ground.
>
> Walking trails is /also/ "boots on the ground". The trail would be part of
> the OSM vector data, though, because it is either artificially created or
> else identified by someone as relevant for connecting 2 points.
>
>> I need to know cliffs. Gullies. Ravines. Gulches. Steep slopes. Hogsbacks.
>> Ridges. Of course roads & structures also are nice to have on those maps.
>
> Yes. And if you US citizens would do your homework in the OSM community,
> they would have been included in the OSM data for years. The topographical
> elements you listed are mappable as (single) objects by the community.
> They do not have the character of contour lines, which are better acquired
> from remote sensing data.
>
>>> The OSM project concentrates on the artificial/cultural aspects of the
>>> topography (streets, buildings, names, and the like). To create maps
>>> containing natural topographic background information from the geographic
>>> OSM data, there's some low-res data available. Users and applications
>>> that need more detailed natural topography include it from other sources.
>>
>> That then is probably the reason why OSM topographic maps suck so bad.
>> Do you see the difference in the zoomed-in section I showed you above?
>
> Why should I watch your sorry US-excuse for doing nothing? I will not cross
> the sea just to do your mapping tasks for you.

Thanks for that background, where almost every topographic map in the USA
seems to stem, fundamentally, from the work of the USGS, which has been
creating openly available topographic maps of the USA since the 1800s.

The problem now, is *finding* OSM topographic maps based on that data.

Even Steve Coast, the OSM founder, said the problem is getting access to
map data. <https://youtu.be/DE2KvtvFOU4>

That's the question here, which is to get access to the map data that
is alluded to in the statement below which was made earlier in the thread.
"It probably has more to do with discrepancies between visual styles
of map rendering than with actual wrong or missing items in OSM map
data."

The goal is to download those OSM topo maps which are based on the USGS
1/3-arcsecond data as the standard OSM contour line maps aren't adequate.
https://wiki.openstreetmap.org/wiki/TopOSM/Details

The Fermi-paradox question is, where are they?
I'm trying to find the answer to that question.
Q: Where can I download USA tiles of reasonable OSM topographic maps?

It was encouraging when you first had mentioned TopOSM two posts prior.

Unfortunately I'm on Windows (and Android) while TopOSM only runs on Linux.
https://github.com/Ahlzen/TopOSM (toposm.ahlzen.com)
https://wiki.openstreetmap.org/wiki/TopOSM

Googling for lectures by Lars Ahlzen, I found this 1/2 hour YouTube video:
https://youtu.be/Fwi-RPtxzEo
I like that Lars emphasized that a map is worthless without the details.
And Lars was happy to be getting those details from the USGS elevation NED
(1/3") along with USGS NHD & MassGIS data on top of the generic OSM data.

But every search I run for good 1/3rd arc-second US data, ends up back at
the USGS such as these links below (none of which are related to OSM maps).
https://portal.opentopography.org/datasetMetadata?otCollectionID=OT.012021.4269.1
https://www.usgs.gov/the-national-map-data-delivery
https://www.usgs.gov/3d-elevation-program
https://www.sciencebase.gov/catalog/item/627f3792d34e3bef0c9a3191
https://www.sciencebase.gov/catalog/item/4f70a58ce4b058caae3f8ddb
https://coast.noaa.gov/dataviewer/#/

I'm still searching for where those TopOSM contour maps are for the USA.
Maybe they exist. Maybe they don't exist.

I don't know yet, but I'm still searching for them.

On Tue, 27 Feb 2024 15:56:14 -0500, Sten deJoode wrote:

> 1. Do you see the huge difference that I see in these two zooms?
> https://i.postimg.cc/bYtQgB42/test1-usgs-vs-osm.jpg
> https://i.postimg.cc/4yP4wZGg/test1-usgs-vs-osm-colorized.jpg
>
> The reason I ask is I hear from everyone how useful the OSM topo maps
> are & yet, when I use them, I find them lacking in almost every way.
>
> (But I had not known about the 1/3 arc-second OSMTopo maps, which I
> don't have yet - but which I will search to find a source of today.)
>
> 2. Can you help me compare the "granularity" of the OSMTopo
> 1/3rd arc-second data versus what I'm currently using, which is the
> 1 inch on the map = 24,000 inches on the ground?

From here
https://apa.ny.gov/gis/shared/htmlpages/metadata/usgs_250dem.html

It says the 1-degree USGS Digital Elevation Model [DEM] is also referred to
as 3-arc-second or 1:250,000 scale DEM data.

The DEM data for 7.5-minute units correspond to the USGS 1:24,000
(& 1:25,000) scale topographic quadrangle map series for all the USA.

There's no mention though of 1/3rd arc second data.
If it's linear (and it might not be) then 1/3 arc second might be 1:25000?

If you are looking for the best possible hiking maps, usable on any
platform, nothing else comes close to the mapant mapping projects
available in a number of European countries:

It started with https://mapant.fi/ in Finland, then we processed about
37 TB of LiDAR data here in Norway and combined that with the official
Norwegian Mapping Authority's topo data to create https://mapant.no/
Please take a look!

(We have WMTS apis available, I use those on my OsmAnd+ android app, but
the web interface is also very usable even on phones.)

Since then we have gotten Spain totally covered (https://mapant.es/),
they might have the best implementation of all currently, as well as
Switzerland (https://www.mapant.ch/ covering both Switzerland and
Lichtenstein). Denmark is currently being processed and Sweden is
waiting on some data access permit.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Tue, 27th Feb 2024 18:43:35 -0500, Sten deJoode wrote:

> almost every topographic map in the USA
> seems to stem, fundamentally, from the work of the USGS, which has been
> creating openly available topographic maps of the USA since the 1800s.
>
> The problem now, is *finding* OSM topographic maps based on that data.

There's only one worldwide OSM database. (Mirrors, extracts for special
purposes or premature data of information contributors aside.) Using the
right tools, it is possible to combine geographic data from different
sources, though. And different programs or services may use different
details, features, ... from the central database when rendering maps
or just checking out data for later rendering.

One program, that can combine USGS and OSM data and export the result to
OsmAnd SQLiteDB or OsmAnd tile formats is the free (and open source)
Mobile Atlas Creator (MOBAC) - a Java program running on several platforms:

https://mobac.sourceforge.io/quickstart

This might be a way to go, if you don't want to wait, until sufficiently
detailed OSM maps and contour lines are available for your area.

> Even Steve Coast, the OSM founder, said the problem is getting access to
> map data. <https://youtu.be/DE2KvtvFOU4>
>
> That's the question here, which is to get access to the map data that
> is alluded to in the statement below which was made earlier in the thread.
> "It probably has more to do with discrepancies between visual styles
> of map rendering than with actual wrong or missing items in OSM map
> data."

I wrote this, because the OSM rendering of your Mount Washington example
didn't look too bad. Detailed contour lines would needed to be included
from a source different than OSM, anyways. But without being rendered
into the OSM map visualization shown, the OSM database may carry much
more detail. Take a look at this page:

https://wiki.openstreetmap.org/wiki/Map_features

Trails, for instance, can be tagged with different attributes like width,
visibility, inclination, difficulty, and more. Deer-hunting stands are
usually not displayed on maps, but can be captured into the database and
rendered, if necessary. Buildings can get height values attached to
enable later 3D rendering. - This list goes on and on.

> It was encouraging when you first had mentioned TopOSM two posts prior.
>
> Unfortunately I'm on Windows (and Android) while TopOSM only runs on Linux.
> https://github.com/Ahlzen/TopOSM (toposm.ahlzen.com)

The script language (Python) and the programs for the TopOSM map creation
process are all available for Windows. But preparation and configuration
efforts are not targeted on normal end-users. And the rendering would take
quite some time, especially when a lot of zoom levels shall be available.

Bernd

On Tue, 27th Feb 2024 18:00:18 -0600, Harry S Robins wrote:

> From here
> https://apa.ny.gov/gis/shared/htmlpages/metadata/usgs_250dem.html
>
> It says the 1-degree USGS Digital Elevation Model [DEM] is also referred to
> as 3-arc-second or 1:250,000 scale DEM data.
>
> The DEM data for 7.5-minute units correspond to the USGS 1:24,000
> (& 1:25,000) scale topographic quadrangle map series for all the USA.
>
> There's no mention though of 1/3rd arc second data.
> If it's linear (and it might not be) then 1/3 arc second might be 1:25000?

That's just a discussion of packaging units. Rasterized contour lines can
take up quite some space. To use this DEM data in combination with other
topographic information, different levels of detail are linked to standard
map tiling systems. (And their boundaries are /usually/ clipped to round
coordinates of the underlying coordinate system: round degree/minute/second
values for geographic coordinate systems; fixed meter/yard/whatever values
for projected coordinate systems.)

The level of detail for each contour line as well as the altitude classes
depicted by separate lines will be adjusted to the typical zoom level of
each tile. This way, small scale maps do not only compress better (and can
therefore be larger and cover more area with the same amount of data when
compared to smaller, but more detailed large scale maps. More importantly,
the readability of the map increases due to the reduced data, when viewed
with small map scales (aka zoomed out).

Bernd

On Wed, 28 Feb 2024 22:02:18 +0100, Bernd Rose wrote:

> One program, that can combine USGS and OSM data and export the result to
> OsmAnd SQLiteDB or OsmAnd tile formats is the free (and open source)
> Mobile Atlas Creator (MOBAC) - a Java program running on several platforms:
> https://mobac.sourceforge.io/quickstart
> This might be a way to go, if you don't want to wait, until sufficiently
> detailed OSM maps and contour lines are available for your area.

Thanks for all your help, which I very much appreciate since you're worlds
ahead of me on using georeferenced map tiles on the device for navigation.

I'm somewhat familiar with georeferencing (eg with oziexplorer & QGis),
so I thank you for letting me know about Mobac, which I had never heard of.

https://sourceforge.net/projects/mobac/
This application creates off-line atlases of raster maps for various cell
phone apps on Android, iPhone and WindowsCE as well as GPS devices (Garmin,
Magellan and others)
Features
Download map tiles from various online maps
Create maps and atlases for your favorite mobile navigation program
https://mobac.sourceforge.io/quickstart" rel="nofollow" target="_blank">https://mobac.sourceforge.io/quickstart
https://mobac.sourceforge.io/
https://sourceforge.net/projects/mobac/postdownload
https://psychz.dl.sourceforge.net/project/mobac/Mobile%20Atlas%20Creator/MOBAC%202.0/Mobile%20Atlas%20Creator%202.3.3.zip
Name: Mobile Atlas Creator 2.3.3.zip
Size: 17200240 bytes (16 MiB)
SHA256: D0481AA5E0268C3CFAA68B962E614F6BD5E67FF18ABA202426097C822A173DE0
unzip
Name: Mobile Atlas Creator.exe
Size: 78336 bytes (76 KiB)
SHA256: 5C1A58F5C92E4FD280AAB877F3EC5ADD5DC4852E17A7B4473195394C408E0C4D

>> "It probably has more to do with discrepancies between visual styles
>> of map rendering than with actual wrong or missing items in OSM map
>> data."
>
> I wrote this, because the OSM rendering of your Mount Washington example
> didn't look too bad.

I agree. The Mount Washington detail in OSM maps surprised even me.
But the *local* OSM contour map detail is so bad as to be almost unusable.
https://i.postimg.cc/4yP4wZGg/test1-usgs-vs-osm-colorized.jpg

I love the idea of OSM and I "hear" people telling me all the time how
great the contour maps are, but I've used them along with USGS maps.

The point is I hear well but I see better. What I want is to see what other
people appear to be saying they're seeing - because I'm not seeing it. Yet.

> Detailed contour lines would needed to be included
> from a source different than OSM, anyways. But without being rendered
> into the OSM map visualization shown, the OSM database may carry much
> more detail. Take a look at this page:
> https://wiki.openstreetmap.org/wiki/Map_features

From that, mainly I care about OSM elevation (ele) information.
https://wiki.openstreetmap.org/wiki/Key:ele

And Altitude.
https://wiki.openstreetmap.org/wiki/Altitude

Which says: "elevation is just an "afterthought" stored in the tag system
under the ele=* and its subkeys"

> Trails, for instance, can be tagged with different attributes like width,
> visibility, inclination, difficulty, and more. Deer-hunting stands are
> usually not displayed on maps, but can be captured into the database and
> rendered, if necessary. Buildings can get height values attached to
> enable later 3D rendering. - This list goes on and on.

I only care about elevation as once there's a trail, you don't a map
(as much as you need that map when they're no trail at all to follow).

The whole point of accurate contours is to be able to pick a hogsback and
stay on it to get from point A to point B on another ridge a mile away.

Once you fall off the hogsback, your entire hike is doomed as you can't get
out of these ravines on terms other than the rule of the ravine, which is
always that you'll end up at a stream and then finally at a lake.

Almost always miles away from where you had intended on going by staying
out of the ridges and only on the hogsback (on all fours most of the time).

Every few minutes you pull your phone out of your pocket to see if you're
still on the ridge as you can barely tell the isocline lines while on all
fours and with visibility being essentially what a rabbit sees all day.

>> It was encouraging when you first had mentioned TopOSM two posts prior.
>>
>> Unfortunately I'm on Windows (and Android) while TopOSM only runs on Linux.
>> https://github.com/Ahlzen/TopOSM (toposm.ahlzen.com)
>
> The script language (Python) and the programs for the TopOSM map creation
> process are all available for Windows. But preparation and configuration
> efforts are not targeted on normal end-users. And the rendering would take
> quite some time, especially when a lot of zoom levels shall be available.

Thanks for that advice. My PC is old, from 2010, so it's not likely beefy
enough - but it works well with the USGS topographic maps as does loading
the USGS georeferenced PDFs into Avenza or into PaperMaps.
<https://www.avenza.com/avenza-maps/>
<https://play.google.com/store/apps/details?id=com.Avenza>
<https://apps.apple.com/app/apple-store/id388424049>

<https://www.paper-maps.com/>
<https://play.google.com/store/apps/details?id=ca.abbro.androidmap>
<https://apps.apple.com/app/nextmap/id1147385120>

In my opinion, Avenza is better, but the free version is artificially
limited to three map tiles (although you can combine georeferenced PDFs so
it's only a matter of extra effort with QGis or OziExplorer to do that).

Thanks for all your help, which I very much appreciate, as I'm a novice.

On Thu, 29th Feb 2024 01:49:16 -0500, Sten deJoode wrote:

> I agree. The Mount Washington detail in OSM maps surprised even me.
> But the *local* OSM contour map detail is so bad as to be almost unusable.

You still mix displayed maps with data. /All/ maps displaying contour lines
will /not/ have OSM as basis for the contour lines; even if they show up
under the label "OSM". The OSM database only carries data for /discrete/
geographic *objects*. Contour lines, OTOH, are a (somewhat arbitrary)
classification of /continuous/ earth surface heights.

Contour lines can neither be mapped nor evaluated by individuals on-terrain.
Historically, sophisticated (and time-consuming triangulation was necessary
to get the data to create a more-or-less accurate height representation of
the earth surface. Nowadays, the creation of contour lines usually is a
geostatistical derivation from remote sensing data.

Different usage scenarios and different zoom levels require other density
(= height classification ranks) and generalization (= smoothing of small
height variations) levels. To cover all possibilities, the OSM database
would probably double or triple in size. Therefore, everybody who wants
to create a map from OSM /with/ contour lines has to find a suitable
source and pick (one or more) set(s) of contour lines from this source,
if different levels of density and generalization are available.
>> Detailed contour lines would needed to be included
>> from a source different than OSM, anyways. But without being rendered
>> into the OSM map visualization shown, the OSM database may carry much
>> more detail. Take a look at this page:
>> https://wiki.openstreetmap.org/wiki/Map_features
>
> From that, mainly I care about OSM elevation (ele) information.
> https://wiki.openstreetmap.org/wiki/Key:ele

This (optional) tag has /nothing/ to do with contour lines. It is a means
to associate height values to geographical OSM *objects*, like buildings,
swamps, or sections of a road or trail.

[TopOSM scripts]
>> The script language (Python) and the programs for the TopOSM map creation
>> process are all available for Windows. But preparation and configuration
>> efforts are not targeted on normal end-users. And the rendering would take
>> quite some time, especially when a lot of zoom levels shall be available.
>
> Thanks for that advice. My PC is old, from 2010, so it's not likely beefy
> enough - but it works well with the USGS topographic maps as does loading
> the USGS georeferenced PDFs into Avenza or into PaperMaps.

Huh?? The TopOSM scripts render map tiles to look comparable to USGS topo
tiles. Once they are rendered, they should not take other computing power
for display than USGS topo tiles. What's time and resource consuming is the
process of rendering the tiles for different zoom levels (with different
levels of detail shown), itself. Information from a couple of different
sources (OSM geographical objects being just one source; elevation and
hydrography are included from USGS data sources) needs to be downloaded,
recomputed and combined for several zoom levels.

Bernd