Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - mark03

#1
I recently updated my phone to Android 11 (LineageOS 18.1), very innocently assuming that I could just copy my existing raster/vector map directories to someplace where the new Locus Classic install would find them.

Close to a full day later, I managed to transfer everything off of the SD card using adb, so it could be formatted, which seems to be a requirement for it to work with the new Android version.  After that headache, I transferred my maps and mapsVector directories back to the SD card and set about making them work with Locus.

Well, obviously, this was only the beginning of my troubles, thanks to Google's "scoped storage" feature :-\

So, I cannot use adb to push my map files into the Locus data directories (because "security"...).  The blanket import functionality in Locus (taking all of the maps at once) also seems not to work.  Finally delving into the official documentation, it looks like I need to import maps one at a time from the maps manager.

This is where I am currently stuck.  I can import maps which consist of a single file, no problem.  But the map I really need is a ~20 gigabyte GEMF which is split into 11 files. If I select the first file in the sequence (the .gemf file), that gets moved into Locus' data directory and appears in the map list.  But it is missing 90% of the data, which is in the .gemf-1, .gemf-2, etc. files.  I cannot find any way to make the importer take these files too.  The file selection dialog does not allow multi-select, only one file at a time.  And importing a .gemf-n file by itself does not work because it is "not a map file."

Any help would be appreciated.  I had no idea this would become such an ordeal :o    Thanks google...
#2
Apologies if this has been covered in the online documentation.  I searched for a while and could not find anything.

I have some very nice LIDAR data for my region (Washington, USA) which I would like to use within Locus.  The resolution is about 1m or a bit finer.  It is supplied as a GeoTIFF raster.

I could make images from this data using GDAL (color relief maps or hillshade maps).  But it would obviously be a lot better to have it integrated properly with another map.  Any suggestions for how to achieve this?  Is Locus capable of taking a raster format like GEMF and displaying it as elevation data instead of image data?  Or is there some format specific to DEMs which I should be targeting?

Thanks,
Mark
#3
I'm writing a Perl script to take GPX navigation files exported from the excellent Dutch Fietsersbond Routeplanner (routeplanner.fietsersbond.nl) and convert them into GPX files I can use to perform navigation in Locus.  This is going to be pretty easy, as I can already tell a lot from studying the navigable tracks exported from Locus (e.g. after a mapquest navigation).  But there is one thing I need:  the list of codes in the <locus:rtePointAction> tags.

These are integers which encode what you are supposed to do at a navigation waypoint, e.g. turn right, turn left, go straight ahead.  I can reverse-engineer some of them, but I hope that by asking here Menion can provide the complete list and save me a lot of effort  ;)

Thanks in advance.

edit
Menion, are you there?  To clarify, all I need is the enum, copied and pasted from the relevant source file.  I can figure out the rest.

Sorry for bumping my own topic but I leave for my trip in a few days...
#4
Hi everyone,

New user here.  Very impressed with Locus!  I hope to use it for hiking in the mountains  near Seattle.  To that end, I've started to research the best way to get US Geological Survey topo maps into Locus (offline).

USGS is transitioning from GeoTIFF to GeoPDF.  A new database of the latest-revised topo maps is now online for free at nationalmap.gov in their "historical topos" collection.  The quality is much better than the "DRG" GeoTIFFs that we have been using for years.  Fortunately, although they are in GeoPDF, the GDAL library (gdal.org) can extract the raster contents and save in a variety of formats.  So GeoPDF is not a problem.

That brings us to the mess that is the mobile map-format space...  Appropriate formats already existed (e.g. tiled geotiff, and a free/open sqlite format---Spatialite and Rasterlite, http://www.gaia-gis.it/gaia-sins/ ---complete with an actual SPECIFICATION  :o).  But, the original players in this space chose poorly (IMO) and so Locus was stuck with a choice:  use a "good" format, that no one else is using, or use formats that actually work with existing software.

Anyway, my goal is to write something in Python to take the GeoPDF rasters and put them in a Locus-compatible format.  I don't want to depend on proprietary solutions like MAPC2MAPC, TTQV4, etc., partly because I am on Linux, and partly because I think it just encourages the proliferation of more useless formats.  GDAL can do most of the hard work here, including the import from GeoPDF, tiling/pyramid creation, and any needed warping / re-projection.  I just need to settle on a target output format, and then I need a spec for that.

Locus sqlite is simple enough, but from what I've been able to understand of some older discussions here, not the fastest?  Then there is RMAP format, and GEMF format, but I can't find documentation or code for either of them.  I guess it is also possible, that by the time I finish a tool, there will be another new format supported!  So I am looking for advice.  What should I target if I want to get this working by summertime?

I was also wondering...
1) Does Locus support multiple image types in its tiled formats?  I exported a simple sqlite and saw that the blobs are PNG.  Can the blobs also be JPEG?  This could save a lot of space, without too much quality loss.
2) USGS topos are [almost] all in NAD27 datum.  Is NAD27 (EPSG:4267) supported in Locus?  Or should I plan on re-projecting into something like WGS84?  I get the idea WGS84 is just "assumed" in some of the simple tile formats... is that right?

Thanks,

Mark