Messages

Here is some weird stuff:
(1) OM will not open a geotif made with gdal_translate from the NSW.spatial GDA2020 geopdf (java error); but it will open the geotif after gdalwarp to WGS84 (which also warns about an ignored/misplaced neatline) - now a moderate size file, but with poor resolution.
(2) OM will open correctly a pdf made with gdal_translate from that 'warped' tif - with smaller size and better (but still degraded) resolution. Starting with the geotif from NSW.spatial then warping and translating as described in previous posts is better (though still slightly lower resolution than the NSW.spatial geopdf).
(3) OM correctly opens the original GDA2020 NSW.spatial geopdf when re-loaded (into either mapfiles or the sub-folder geopdf). Now it does not give either variable georeference errors or variable problems with zoom (experienced previously). Likewise, a re-loaded (large) pottsville1.tif now works in OM. Maybe it was some subtle corruption on copying the files? Now I am nervous - you can see the evidence in the previous screenshots.
(4) The re-loaded files do not show at first in OM, even after refresh maps, but they do show in subsequent starts (probably a little bug in OM, not a problem after the second start). 

I worked on this a bit more. The CollarOff versions of the maps from the NSW.spatial website are in geotiff format, and AsTiffTagViewer shows that the 2020 maps specify GDA2020 in metadata. But they will not open in OM (version 7.4.28). Nor can OM open geopdf maps converted from the 2020 Pottsville geotiff using the (very slick) online converter at https://gdal3.js.org/; though Adobe Reader opens these converted files without problem.

One workaround is to use Map tweaks > Map calibrator in OM, though it is not entirely satisfactory (probably because it uses only a single point to calibrate).

What did work well for me (after I downloaded the geotiff file from NSW.spatial to C:\temp\pottsville.tif) was to use gdal programs: first gdalwarp -t_srs EPSG:4326 C:\temp\pottsville.tif C:\temp\pottsville1.tif (to get a WGS84 re-projection - though it will still not open in OM), then gdal_translate C:\temp\pottsville1.tif C:\temp\pottsville1.pdf to get it into geopdf. This aligned perfectly under my track in OM (better than the 2016 geopdf map direct from the NSW.spatial website, which has that slight E-W error). Whew, what a run-around.
You cannot view this attachment.

The cached wms maps from NSW.spatial align perfectly under my track, so the errors seem to be associated with OM handling of the geopdfs.
You cannot view this attachment.

I think the take-home message is that OM (version 7.4.28) is happy with WGS84, but may be confused by at least some pdf maps in GDA94 or GDA2020 (these are not listed under OM Map tweaks > Map Datum, but at inception they were very close to WGS84).

Ype, OM is designed to work for many users with different needs, so the learning curve for any one use is steep - but worth the effort.

The 'free' version is no longer highlighted on the OM home page, but it is still available (in v 7.4.28) at https://www.oruxmaps.com/cs/en/more/downloads. It is fairly dependent on use of (non-intuitive to many people) icons, which can change between versions. It is part-way between the description in the manuals for v7 and v8. But the manuals are missing many features, so you have to discover them by experiment, or ask questions in this forum where expert users like Tronpo (who some members call Trompo for reasons unknown) are very helpful. If you like it you should donate, which is made easy on the homepage. The main drawback is that the developer seems to be lately more occupied with Versions released for payment on places like Google Playstore, so if you find a fault in 7.4.28 you may be waiting a long time for a response or a fix.

To find the latest (and available) beta, look under BETAS on this forum. It will be much more like the current version on Playstore (and much more menu driven). The disadvantage is that it respects the new Android requirement for scoped=private storage by apps. This makes it harder to do some of the File Management in OM, especially in Android14. It also corrupts some existing user files when it tries to move them from the old (root>oruxmaps) to the new (Android>data>...>oruxmaps). But it is probably the way to go for a new user. There seems to be no user manual yet, but the app now has more inbuilt help. Ironically the version on Playstore (for which you must pay via Google, probably much less than you would otherwise donate via OM) is dubbed the "donate version" (go figure). If you go this way you can get automatic updates via Playstore, and probably a better chance of a fix if you find a fault.

Some new geopdfs seem to give a georegistration error in OM. For example, the 2022 (NSW, Australia) geopdf Potsville 1:25K seems to be incorrectly georeferenced in OM (about 100 m N of actual location). This error is not present in the 2016 version of the same map (although it was slightly west of true location in OM). According to metadata shown by TerraGo, both versions use GDA94 (athough the new ones are distributed as GDA2020). In any case these datums are very close to WGS84.  Both map versions give the same (I assume correct) location in Adobe Reader Geospatial Location Tool.

The full reference to the map with the biggest problem in OM is: 9641-3S Pottsville 4th Edn CollarOn_2022 (at https://portal.spatial.nsw.gov.au/portal/apps/webappviewer/index.html?id=06e3c2e0de1e4efda863854048c613c6).

The screen shots are from OM 7.4.28 with a track overlay. Is there a problem with the way OM interprets metadata (Geo Registration?) in the new files?

Here are some screengrabs that might help to show the problem:

1. Just the waypoints (nice and clean).

2. With route made on map-screen in OM. Note the added default-symbol waypoints and overlapping names (yuk).

3. With route imported to OM from GPX. Note the added default-symbol waypoints and overlapping names, even though they are the same as the wpt names and map positions already in OM (yuk).

4. Garmin (BaseCamp) allows the route to be made on map-screen, using the existing wpts, so it is nice and clean (no duplicates, let alone overlapping ones). Seems like this should also be an option in OM?

Hi Tronpo, thank you for your interest. (I have noticed that your inputs and feature requests are typically very well reasoned.)

The limitation in OM comes before the steps that you mention.

As far as I can see, OM can not create routes from waypoints on the map screen. It requires the user to put the relevant waypoints in a separate (or filtered) list, and order them, without being able to see them at the same time on the map. As mentioned above, this method of creating a route from an ordered list of waypoints (without seeing them at the same time on a map) is very difficult for users who have lots of waypoints and use complex routes.

If the user instead tries to create the route on the map screen (even with the user's waypoints displayed) OM always creates a new waypoint/routepoint (with a default icon) at some nearby map location and ignores the user's waypoints (which of course are at the location that the user really wants). Then when the route is loaded for waypoint navigation along with the users waypoints there is a big mess - with superimposed icons and names.

Incidentally, something similar happens even if the route is imported from a GPX file. Because OM looks in the <type> field for waypoint icons, whereas most other mapping programs use the <sym> field, the default waypoint icon is assigned, and the same big mess follows on screen, unless the user each time modifies the imported route waypoints to use the icons already assigned to waypoints of the same name and location in OM. There are several ways to do this editing, but all take time, and all have to be repeated for each imported route.

I appreciate that the concept/model for use of waypoints, routes and tracks is somewhat different in OM vs Garmin; but it seems to me that what I requested would improve OM for many users (and hopefully it is not too hard to code).

I use OM 7.4.28, but I have checked up to 10.5.3beta18, and (if I can use a Titanic analogy) the changes seem to be mostly rearranging the deckchairs, with few added iceberg avoidance features. But unless users tell Orux, he can not know what they really want. Hence this thread.

What one feature would you most like to see added to OM? Not your wish-list, just the top wish.

Would you pay (more) for it?

If you agree with a feature request, +1 it. How else will Orux know if it is a popular wish?

I will start the ball rolling:

When creating a route on the map screen with waypoints loaded, can we please have an option if we 'hover' over a waypoint to use that waypoint instead of some nearby map location as a route point? Garmin Basecamp does it well. This is very useful for waypoint (= direct, = straight-line) navigation when off-track hiking (so we can see the distance and magnetic bearing to the next waypoint if we choose that in the top dashboard). The current method of creating a route from an ordered list of waypoints (without seeing them on a map) is very difficult for users who have lots of waypoints and use complex routes.

Yes, I would pay (more / again) for this feature.