Where to help

Check out the announcement blog post for a quick overview of how I put together the first version of Desert Atlas.

If something below sounds like something you can easily help out with, or even offer a bit of advice on, it would be appreciated. The first version of Desert Atlas was created with a surface level understanding of a lot of different things. If you have ideas not listed here, I'm all ears, and of course you could just take a look at open issues.

I would just ask that you reach out (creating a new issue, commenting on an existing issue (which I try to link below), or starting a discussion) before committing a lot of time, just to make sure we're on the same page about where to take things. I don't want people to dive in with a lot of work that doesn't end up working out.

Low Hanging Fruit

Space efficiency (sqlite3 familiarity)

• Note: At some point we will want to Switch to Nominatim lite which means sqlite-specific stuff will be out of our hands. So the following may not be a very high priority. Then again I don't know when it'll be out so it's worth considering.
• See this issue
• sqlite3 vacuum. Run this after every import or delete?
• sqlite3 - anything that could shrink the database?
  • It's mostly text. The csv files I import compress so well and expand into a comparatively huge database file. I would even be open to having the db compressed on disk but decompressed into /tmp just to run, though that runs the risk of being slow to start.
• Don't copy the osmnames database (cities and large towns that are searchable before downloading regions) in every grain? It takes up a lot of space for an empty map.
  • Instead, have the osmnames database file be part of the app (won't take up more space for each new grain). Each search request would then query the osmnames database database and the (single) database containing the data from the imported downloaded regions CSVs. (maybe using this feature?) Or, maybe query one or the other depending on zoom level, etc?

UI/UX, Design, Leaflet

• Assuming we keep leaflet (see below regarding MapLibre GL and OpenLayer), anybody generally good with UI/UX or even copywriting could probably clean things up.
• Icon size during tutorial
• Anybody with design sensibility can see I need help! For example...
• Switch bookmarks (back) to scrollable instead of paginated (Leaflet captured mouse events and I gave up on it).
• Whatever usability improvements that you suggest from trying it out

Rendering (OSM familiarity)

• Switch to MapLibre GL (which iirc looks nicer) or OpenLayers (haven't checked out)?

Data in tiles (OSM familiarity):

• Improve the data contained in the pmtiles files, and how it's displayed (keeping in mind that changing to MapLibre GL or OpenLayers might affect the latter)
• Fix up land area types and water (earth, ferry, water names (without the extra lakes everywhere!), etc. Compare with openmaptiles-based lua script.
  • In particular, water is kind of messed up right now. See NYC for the worst example I've found. See here for details.
• Show housenumbers, though I think Protomaps on Leaflet doesn't do this normally. Would need to edit protomaps.js (or the equivalent for MapLibre GL or OpenLayers).
• Less car-centric items on the map
• Replace the geojson empty world map with a nicer pmtiles based one that's super low res so it doesn't take up more disk space.

Data in search index (OSM familiarity)

• Switch to Nominatim lite (I learned about this one late, it may well obviate the below items)
• I want to start adding more OSM metadata to the search index, which would give the user options and maybe can be used in plain search otherwise. I describe it in this issue for the sake of displaying to the user but it would also make it available for search.
• Less car-centric items to show up in search
• Look at relations when extracting serach data

Basic improvements to search (sqlite+fts5 familiarity)

• Switch to Nominatim lite (I learned about this one late, it may well obviate the below items)
• Search non-latin characters
• Short queries
• Make "&" equivalent to "and"
• Searching for nearby items across the 180/-180 longitude line

Browser/App integration

• Detecting support for map:// and geo:// links so users know before they try.
• "Open in external app" failed in Fennec browser (if it fails here it might fail in Firefox overall)
• Import kml from Organic Maps -> Desert Atlas (We only have the other way around)
  • UI-wise on Android at least, I wonder if we can avoid having to mess with the file manager, but I doubt it
  • If we endeavor to do a sync API (see below) this may be obviated, but that's long term

Backend rewrite from Python to Go

• For performance (start-up time in particular), memory, package size, and threading (concurrent downloads, probably other things)
• This is something I have familiarity with, but I plan to split it up into parts that I could delegate.

Basic frontend code cleanup (JS/Typescript familiarity)

• Clean up the code, maybe multiple files, etc
• TypeScript - I may want to try Go/WASM, but in the short run Typscript is probably a good idea if it's quick.
• Do everything using Debian packages? I'd like to continue to avoid npm if at all possible.

Anyone who's generally familiar with OSM, Protomaps, etc etc.

• let me know any way I'm doing something stupid, inefficient, etc.
• let me know if there's a cool feature or enhancement that I'm not using!

Some less easy stuff:

• Split planet.osm.pbf into "administrative regions" (countries, states, parts thereof for big ones, etc, like Organic Maps does) instead of rectangles. See here.

  • Geofabrik's extract process. They don't publicize their actual scripts.
    • The limiting factor of their download policy is per-file, which prohibits simply downloading (for instance) every country individually in one day. That said, it does allow for downloading every continent, in case that helps somehow.
  • I've also heard of use of BBBike's extracts. I don't know what all they could offer.
  • I've heard osmium-tool is the way to go. If you know this tool, please chime in!

• Searching addresses

  • Related to this one but I assume there's a lot more to address search than simply matching street name and number in a fuzzy search. That said if we can get 80% of the way there with that I'm for it.

• Navigation? Very low priority. You can export to Organic Maps for that.

• Parallelize the build process by region.

  • Right now it takes ~2.5 days to build the planet. Splitting the world into rectangles is maybe 10% of this time. Each rectangle could be independently prepared in different Nanodes, Lambdas, Kuberneteses or whatever.

• Copy the NextCloud API as a more convenient option than importing/exporting KML files. Get support for a few clients like (iirc) Organic Maps and Gnome Maps this way.

• Port front end to Go/WASM. Sounded like an interesting way to avoid the javascript ecosystem.