Preferred offline raster format, five months from now?

[joeloc]

How much longer do you think desktops will live? The sooner you cut off all dependencies, the better you'll be prepared...

But anyway, all this geotiff/python/tileserver/conversion things is mainly for power users. I think the "normal guy" would benefit most if you could strike deals with mapping companies and offer in-app download purchases or whatever. Sad but true...

Talking formats, The advantage of rmap was mainly that it is supported for export by ttqv and compeland, who in turn have deals with many commercial map providers. So in theory, users dont need to dive down to command line level to create locus mapa.

[joeloc]

Btw... i still cannot believe that todays devices would have any issues whatsoever with decoding geotif. Whats all the scaryness about? Its just a few tiles with a few coordinates and some raster data and overviews or not. Why would that be any problem at all, cpu or battery wise? What hyper complex tiff implementation details am i missing?

Of course it needs a bit more code than something as simple as rmap. But once the code is there, wouldnt it run just as efficient?

[joeloc]

another idea: in one years time, osm will beat all commercialy available maps both in accuracy and rendering quality everywhere on this planet. so all thats really needed is advancements in mapsforge, custom raster data is a dying thing of the past

just kidding...

[mark03]

How much longer do you think desktops will live? The sooner you cut off all dependencies, the better you'll be prepared...

I'm very much a "live free or die" kind of person, so personally I hope the desktop, or something like it, lives forever.  I like my phone, and I'm impressed with my parents' iPad, but if the walled-garden / app-store model of computing is our only future, we will have lost something profound.

(Please note, when I say "free" I mean free in the sense of freedom, not in the sense of price.  I have no problem paying for quality software like Locus Pro, but I don't like proprietary interchange formats, so I don't care what TTQV4 or Compeland happen to use, unless those formats are open, like geotiff.  And, top priority should go to supporting those formats used in open-source software like GDAL, because that ultimately makes the world a better place.  BTW, geopdf seems to be going the way of pdf, i.e. an initially proprietary format shoved down our throats but eventually standardized and open.  All of the $$$ for one company while sort-of keeping the moral high ground  :roll: )

If you're interested in some radical speculation on the future of mobile vs desktop computing, I highly recommend Cory Doctorow's recent keynote at the 28th Chaos Computer Conference in Berlin, "The Coming War on General Purpose Computation":

http://www.youtube.com/watch?v=HUEvRyem ... r_embedded

Sorry for the tangent.

[joeloc]

I totally agree with free and open formats. Unfortunately, thats not how the mapping world works today. In the end, the user buys a dvd from kompass or ign with a pretty map and then wants to use his map in Locus. How to make this as easy and painless as possible?

Right now this involves hunting down OziMapTrans in the dark web on some shady download sites, convert tne proprietary dvd to geotiff, then download free ttqv demo version, import the geotif, export to rmap.

Not impossible, but still a major hassle. How to make it simpler? I dont know. But another custom format unfortunately wont help a lot.

Ps, sorry for posting so much. Sitting on a beach on gran canaria waiting for the night... a bit boring

[mark03]

Astronomer, eh?  That's my hobby too.  Lucky you, in Gran Canaria!

The way it seems to work here in the US, at least for topographic maps, is

1)  The data are free, but sometimes inconvenient to obtain, as the govt doesn't like spending money on fast pipes.
2)  Commercial entities take the free data, and convert to a proprietary format that only works on their GPS, or in their software (e.g. National Geographic TOPO!).  They also make sure their HW and SW won't read the free formats.
3)  Profit!!

(As you can probably tell, I don't have respect for this business model.  I think it is fundamentally immoral.)

My starting premise is usually that the data are free to begin with.  When this is not true, then the rules change...  e.g. it used to be like that for roadmaps, but as you noted OSM is dragging nav data into the free world too.  Good times!

[pvb]

Hi, I am using Locus with my own GIS data layers, using Maptiler and MOBAC to create the RMAP SQLite maps. These are both free (open source) tools which work on both Linux and Windows. See my blog http://pvanb.wordpress.com/2012/03/19/c ... bile-maps/ for a short tutorial. It involves a few steps, but once you get the hang of it it is simple enough

on the topic of the multiple formats, it certainly is a pain, but MOBAC seems to be able to convert quite a few mobile map formats back and forth, with the added advantage that you can create the same map for different mapping apps with virtually the same effort.

Edit; of course, Maptiler and MOBAC are desktop solutions, so not everybody in this thread will be happy with it, but I am not sure how soon you will see mobile apps that can do the same, not for very large maps anyway.

[kerenoc]

Hi

I'm a very happy user of Locus and I use it with topographic maps from France generated with GDAL/MapTiler and Mobac (a tool chain very similar to the one used by pvb.

Planning a trip to the US, I'd like to do the same with USGS topo maps. So far, the TIFF or PDF maps of the 7.5 series I've found all include a border around the real map containing the legend. This border is annoying if you want to stitch several maps together before generating the Locus maps (for example, to cover the whole Yosemite valley in a single database) as the maps overlap. Does anyone know a way to automate (with Python for example) the stitching process? In theory, one should be able to calculate the georeferences of the 4 topo map corners within the larger map.

Alternatively, does anyone know a tile server for this kind of map?

[joeloc]

GlobalMapper has an option to auto-crop these types of borders when loading tiles. It sometimes works nicely and sometimes not at all. Not sure if this is available in the demo version, you d have to try it out.

[kerenoc]

After some searching on the web, I found a small open source program Quadjoin written by Frank Glandorf that does exactly that I wanted, stitching 7.5 topo maps. When tested on the Grand Canyon area after some Maptiler processing, I found a little offset of a few meters on longitude but it is also present in the original geotif files from the USGS (using the projection description included in the file).

Vive le web et l'open source (as we say in French)!

[arcticgps]

It would be very powerful of locus could read or import geotiffs directly. It is an old format but very universal. I haven't tried importing custom rasters yet but I will be looking at this in the coming weeks.

While the open SQL raster is berry efficient and powerful if locus could read geo jp2k files directly it would be very cool. Jpg 2000 is an efficient wavelet compression and I believe an open format. I have been horsing around with converting raster formats for mobile platforms.for 15 years and having a mobile mapping program that you could just drop your own custom images on would be a game changer.

[mark03]

Hey, I'm back with an update on my USGS topo-mosaicking project.

I ended up going with the GEMF format, just because it is documented, and RMAP really isn't.  Also, there was python code provided to generate a GEMF file from a directory structure containing the raster-tile "pyramid."

I am starting out with the "historic" USGS GeoPDFs, which are the same maps as digital raster graphic (DRGs), but re-scanned at higher resolution and archived in one place for the whole country.  I had to get the complete list for the state of Washington, sort it in a spreadsheet, then write a script which attempts to pick out and download only the most recent version of each 7.5' quad.  This is an error-prone process, because many of the names are not perfectly consistent over time; for example, "Mountain" becomes "Mtn" or "Mt" and so on.  So it requires some manual intervention...

Next, GDAL tools are used to extract the rasters from each GeoPDF at 400 dpi.  At the same time, the "neatline" from the GeoPDF metadata is used to remove the map collars, and the maps are warped from whatever projection/datum they had in the GeoPDF, to the google-maps standard EPSG:900913, with the result saved as GeoTIFF.

Then, I use a modified version of the gdal2tiles.py included in the GDAL distribution to simultaneously mosaic a bunch of these GeoTIFFs and save the result as a tile pyramid at zoom levels 10-16.  (Modified, because out of the box it only supports PNG tiles, and I want JPG--much smaller with negligible loss in quality.)  This is the interesting part, as I have only tried a set of four quads; my goal is to mosaic ~1000 of them (the whole state).

Finally, a modified version of the python code on the GEMF web page takes the tile-pyramid directory structure and packs it into a GEMF file.  Transfer to my phone, and voila!  It performs great in Locus!

So the whole thing is done using open-source tools, and best of all, it's entirely at the command line--no GUIs.  Scriptable FTW  

I hope to have some larger GEMFs to play with in another week, and will report back here.

Does anyone know the file-size limit on an Android-formatted SD card?  Is it 2 GB, 4 GB, or something else?

Mark

[tommi]

Does anyone know the file-size limit on an Android-formatted SD card?  Is it 2 GB, 4 GB, or something else?
Mark

We had discussions here in the forum: 2GB for Android 2.x, 4GB for Android >=3.
However taking into account that most phones use 2.x one should consider that sharing maps >2GB will restrict the usage to few phones/users.

[mark03]

We had discussions here in the forum: 2GB for Android 2.x, 4GB for Android >=3.

Thanks.  The whole state of Washington will probably come in near 32 GB, so I may split into west/east.  GEMF has support for splitting a single map across multiple files.  I hope Locus' GEMF implementation supports that...?

[Menion]

Tommi are you sure with 4GB limit on all 3+ devices? I did not tested it, but if this is true, I can change all possible testing I do in Locus to prevent using maps bigger then 2GB on all devices. May anyone other confirm that such map work in Locus or any other program?