The k7e Project

Which map scale should we do first for phase 2?

  • Something else (please comment)

    Votes: 0 0.0%

  • Total voters
    10
k7_water_nw_by_ashtagon-davjj9b.png


http://ashtagon.deviantart.com/art/K7-Water-NW-657641279

Part of my long term map making goal is to make a high resolution map of the world. I favour Kavraisky VII projection because the formula to determine what any given pixel is is really simple, so I can either use g.projector to make projected versions (as above) or (eventually) use a combo of a spreadsheet and google earth to determine where on a globe a pixel is and read the terrain and political ownership off a real world map.

But that step is not yet. Phase one involves making abase map. Due to hardware limitations, I will be working on one quadrant at a time, starting with the north west part.

When making my maps, I use the following shortcut names for the projections.

  • K7a: Kavrayskiy VII, normalised to a width of 1250 pixels
  • K7b: Kavrayskiy VII, normalised to a width of 2500 pixels
  • K7c: Kavrayskiy VII, normalised to a width of 5000 pixels
  • K7d: Kavrayskiy VII, normalised to a width of 10,000 pixels
  • K7e: Kavrayskiy VII, normalised to a width of 20,000 pixels (the linked map above)
 
The published world altimetry & bathymetry map is k7c scale. I haven't yet made a formal attempt at rendering the others (and probably will only ever do k7a, k7c, and k7e scales).
The map scale naming scheme is more intended to provide a consistent naming pattern for the future. Someone once suggested "ashbam", but the lower numbers are hardly big ass maps, and the projection owes more to Mr. Kavrayskiy truth be told.
 
The published world altimetry & bathymetry map is k7c scale. I haven't yet made a formal attempt at rendering the others (and probably will only ever do k7a, k7c, and k7e scales).
The map scale naming scheme is more intended to provide a consistent naming pattern for the future. Someone once suggested "ashbam", but the lower numbers are hardly big ass maps, and the projection owes more to Mr. Kavrayskiy truth be told.
So if I wanted to make k7b without a spreadsheet, I'd just quarter k7c and correct for missing pixels?
 
So if I wanted to make k7b without a spreadsheet, I'd just quarter k7c and correct for missing pixels?

In this thread, I plan on documenting the process so that you would be able to computationally create these maps without any "drawing" involved. The process of adding the coast lines creates some inevitable pixellation, and reducing from such a map would simply compound that error.

I plan on starting with k7e because ridiculously big maps seem to be the current fashion (also, I want a good base map to draw my English civil war maps on).

Phase one of rendering these maps involves rendering (modern) national borders and coast lines. These will be derived from NASA's hi-res maps. One issue I have discovered is that my process as far as this phjase goes will over-estimate the width of most rivers. At the equator, each pixel nominally represents about 2 km, and some really big rivers get rendered as 2-3 pixels wide (about 5 km). Certainly, some rivers do get this wide, but I'm not sure this is as common as the map would imply.

Phase two would involve using a spreadsheet-generated kml map grid overlaid on google Earth, and eyeballing what each pixel should be. Any over-estimated river widths would be corrected in this phase. Due to the way g.projector renders maps, it is possible that there may be widespread adjustments north or south by a pixel or two at this phase.

My to-do list is roughly as follows:

* Complete phase one for k7e, k7c, and k7a
* Create a spreadsheet and set of kml files that can be overlaid on google Earth.
* crowdsource phase two for the above three map resolutions.
 
So one of the steps in this process amounts to the following:

  1. Reduce map to 1-bit (ie 2 colour depth - black and white only).
  2. Delete (enblacken) every white pixel that is not directly adjacent to at least one other white pixel.
Is there any way to automate this process (I am using paint shop pro)? Because Canada may be rather heavy going for this kind of manual step.
 
Zooming in on a 1-bit black and white version of Canada's lakes is feeling a lot like a freeze-frame of Conway's Game of Life.
 
Zooming in on a 1-bit black and white version of Canada's lakes is feeling a lot like a freeze-frame of Conway's Game of Life.
Just ran a section of the above quadrant in Golly. ...huh. By 20 gens in, the black=no life one still looked almost recognizable.
 
k7e_water__nw_quadrant_by_ashtagon-dawfr23.png

k7e_water__sw_quadrant_by_ashtagon-dawfr3x.png

NW: http://ashtagon.deviantart.com/art/K7e-water-NW-quadrant-659144379
SW: http://ashtagon.deviantart.com/art/K7e-water-SW-quadrant-659144445

The technique:

With the previous map,

1. Reduce it to 1-bit colour depth
2. Delete any lone white pixels (those not directly adjacent to at least one other white pixel)
3. Select all the black pixels (selections > modify > select colour range > add black (low tolerance) from selection)
4. Reduce the selection away from the edges (selections > modify > contract > 1 pixel)
5. with selection, replace black with green
6. Cancel selection
7. Replace white with blue.
 
Last edited:
Why do we need two?

The qbam maps have a lot of problems. The Americas are shifted west and the old world east. Many Islands are drawn larger than they should be. In many areas coastlines are wonky.

K7 projections allow individual pixels to be assigned to specific latitude longitude coordinates (actually to a rhomboid area mapped on to a sphere). The formula for this mapping is sufficiently simple that it can be objectively checked instead of relying on good quality artwork. This makes them objectively better than qbam.

I am aware that these first-pass maps overestimate the size of most rivers. This is a result of pushing the upper limits of ghetto resoluton of my source data. Phase 2 should fix that.

To be fair to qbam, it is an incredible effort for what I suspect to be a hand drawn map. But given its known flaws and the availability of better tools, we can do better now.
 
I of course am a big fan of your work, Ashtagon (this you know)! And although I am salivating at the thought of working with the k7e, I'm going to have to pressure you to finish the k7c first. The main reason is because we desperately need a replacement base for the QBAM, which has no definitive version and as you pointed out is incorrectly proportioned. I also don't know why you put the k7a up for a vote, as you've already finished that, have you not?
 
Just woke up with a bit of an epiphany; the "clean up all the one-pixel water areas" step is entirely unnecessary, since it'd all get picked up in the phase 2 step anyway. I'm going to re-upload the two previous maps before uploading the next ones, this time without that unnecessary and laborious step.

In the meanwhile, here's a map centred on the Pacific I did as a request.

k7d_water__pacific_by_ashtagon-dawfo30.png


http://ashtagon.deviantart.com/art/K7d-water-pacific-659140524
 
Last edited:
Question regarding rivers and phase 2:

My original plan for drawing in rivers was essentially "Draw the pixel as a river if a line of water crosses the space and at least 25% of the area is on each side. If this results in a discontinuous line, go back to the pixels relating to the break in the line, and pick the pixel that the water is 'most' in to make the line continuous."#

However, zoom in hard enough, and there are water lines (rivers, streams, brooks, channels, gulleys, what-have-yous) literally everywhere. Does anyone have a good objective way to pick how much of a river gets drawn? Which tributaries, how far upstream, etc.? Bear in mind that ideally this needs to be something visible on google maps or an equivalent.
 
Top