hexagram30 / map Goto Github PK

See the following:

• https://www.weather.gov/jetstream/models
• https://www.weather.gov/jetstream/mos_max
• https://www.weather.gov/jetstream/300mb (locating the jetstream)
• https://www.weather.gov/jetstream/500mb (locating precipitation fronts with vorticity)
  • Model: https://en.wikipedia.org/wiki/Barotropic_vorticity_equation
  • Blog: http://lukemweather.blogspot.com/2012/05/simplest-kind-of-weather-model.html
• https://www.weather.gov/jetstream/700mb (identifying humidity zones)
• https://www.weather.gov/jetstream/700mb (actual precipitation)
• https://physics.stackexchange.com/questions/145724/atmosphere-model
• https://software.nasa.gov/featuredsoftware/earth-gram-2016

Open sourced weather models:

• http://www.met.rdg.ac.uk/~mike/dyn_models/igcm/

This would most likely be ASCII representations of caves.

Tasks:

• Identity a good noise library
• Create a prototype app for it (see hexagram30/noise#1)
• Create a docker image for the app (see hexagram30/docker#3 & hexagram30/docker#4)
• Convert the app into a gRPC-based service
  • Consider running a gRPC service - hexagram30/noise#2
  • Define gRPC-based execution flow - hexagram30/noise#3
  • Implement gRPC service - hexagram30/noise#4
  • Generate Go lib for noise service
• Update the CLI to generate caves - hexagram30/cli#6
• Devise mechanism for assigning caves to geophysical location on map
  • With a pixel representing ~1000km², many cave systems could fit on a pixel
  • Subpixel indexing will be needed, following on the Hilbert curve work being done in hexagram30/raster#25
  • Provide a means of storing caves in the raster service's DB (see hexagram30/raster#27)
• Support image-generation of cave raster data
• Support ASCII-generation of cave raster data
• Provide a means of linking generated caves in support of creating cave systems

Note: some or all of this ticket is being superseded by hexagram30/raster#15 ...

Once the biome lookup work is done (#23), let's add land cover support:

• Create a mapping of biomes to % land cover for types of vegetation.
• Then create a map ... since each pixel covers a large square area (taking most of a day's travel to walk across), mix up the coverage. (E.g., If a biome has 10%, 15%, 50%, 5%, and 20% composition of different types of vegetation, make sure that each of those is somewhere between 50-80% the primary vegetation type, and comprised of some portion of the others. Since color will only indicate the primary vegetation cover, the secondary types will need to be tracked in a data store.)
• Add support for seasonal variation: season count, season types, percent coverage change during those times, maybe even completely different coverage in different seasons ...

Also create config functions.

When working on ticket #23, I did some simple curve sketching in a Maxima-Jupyter notebook, and that should get added to the repo, for future reference. Probably, #23 should be updated with a linke/commit id as well ...

Note: this ticket is being superseded by hexagram30/raster#15 ...

Tasks:

• Generate .bmp for lakes
• Add lakes layer to layers component
• Add lake? flag to tile
• Update tile processing to support the lake? flag
• Ditto to all the above for inland seas and sea?

Also create the config functions.

• Gather general biome data
• Add temperature, elevation, and precipitation scales
• Add temperature, elevation, and precipitation maps
• Add a temperature map adjusted for elevation
• Create a biome-mapping based on one of the accepted models in the field
• Create one or more data structures to implment this mapping in Clojure
• Generate a new world map with all the biomes
• Analyze results to see if global temps/precip maps need to be adjusted

• Use the new biome mash-up image that was published to Twitter: https://twitter.com/hexagram30/status/1210479126534148096/photo/1
• Add smaller images ... maybe color alt, bw alt, and temperature?

Some initial images have been added , Resolution was arbitrarily set to 1600x1020. These notes are in the config file:

   :pixels {
     ;; With these values, one pixel is approximately the area of a city
     ;; whose size is between that of Chicago and El Paso, ~ 626 km^2.
     ;;
     ;; Walking for two pixels is approximately the same distance as walking
     ;; the length of the Chunnel (between England and France), or 50 km.
     ;;
     ;; Note that the average size of a medieval "city" was ~ 2.6 km^2. As
     ;; such, in one pixel you could fix 100 medieval cities. Which, of
     ;; course is absurd ;-) But! If one uses the oft-quoted measure of
     ;; placing cities a distance that can be walked, there and back, in one
     ;; day, one pixel can hold, for example, one whole city (10 mile radius),
     ;; two halves of two cities, and one quarter of another city.
     :x 1600
     :y 1020}

Which, of course, begs the question: what is a good resolution, really? How granular do we need to get? Things to consider:

• player traversal (as a player crosses a grid, how much time will it take? how much can the land change?)
• city/town sizes: how many towns/cities do we really want in the area of a pixel?
• what precision do we want to use when referencing object/sentient coordinates?

Tasks:

• Figure out how much data would we need to store for several different resolutions
• Explore game units (i.e., distance) to use
• Consider travel times, rates of travel on foot
• Come to a final decision
• Document the work done here
  • update/add docs
  • add to code

Tasks:

• Generate .bmp for swamps
• Add swamps layer to layers component
• Add swamp? flag to tile
• Update tile processing to support the swamp? flag

From work done on:

• Ticket hexagram30/raster#25
• Spreadsheet https://docs.google.com/spreadsheets/d/1IBeVdiIy4LyOaXEWL3bd1EKOJaQ_87AwR16t5MwPd6M/edit?usp=sharing

we need to standardize on the following resolutions:

Image changes needed:

• 3600x2300 (large) → 3072x2048
• 1600x1022 (medium) → 1536x1024
• 500x319 (small) → 768x512
• 240x153 (tiny) → 384x256

Also, the README will need to be updated:

• Add a new "resoltions" section
• Populated it with the info above and some descriptive text, rationale, etc.

Note: this ticket is being superseded by hexagram30/raster#15 ...

Add distinction for leeward/windward (i.e., take elevation as well as direction into account).

Check out the following:

• https://medium.com/universe-factory/climate-modeling-101-4544e00a2ff2
• https://www.climate-charts.com/World-Climate-Maps.html
• Jetstream: https://www.weather.gov/jetstream/300mb

See:
Ondrej Nepozitek:

• https://ondra.nepozitek.cz/blog/42/dungeon-generator-part-1-node-based-approach/
• https://ondrejnepozitek.github.io/ProceduralLevelGenerator/docs/introduction.html
• https://github.com/OndrejNepozitek/ProceduralLevelGenerator
• https://github.com/OndrejNepozitek/ProceduralLevelGenerator/blob/text/extended_paper.pdf
  Chongyang Ma:
• http://chongyangma.com/publications/gl/index.html

Note: this ticket is being superseded by hexagram30/raster#15 ...

Tasks:

• Explore Voronoi-based river generation - #19
• Explore BMP/pixel-based river generation - #20
• Generate .bmp for rivers
• Add rivers layer to layers component
• Add river? flag to tile
• Update tile processing to support the river? flag

Note: this ticket is being superseded by hexagram30/raster#15 ...

Now that #23 is done, let's integrate it into the map service ...

Once the rainfall map is created, use that in conjunction with the forest biomes to determine where rainforests are.

Contributing factors:

• tropical rainforests accumulated annual precipitation between 2500 and 4500 mm
• temperate rainforests:
  • occur in oceanic moist regions, windward wide of mountains
  • accumulated annual precipitation over 1400 mm
  • mean annual temperature between 4 and 12 °C

Might be good to also generate a .bmp file that shows this ...

Sinusoidal data:

• 89 latitudinal lines for each degree between equator and pole
  • ~10,000km distance (at 510 pixles -> ~ 20 km per pixel)
  • between equator and pole, a degree every ~ 5.7 pixels (/ 510.0 89)
  • between equator and pole, every pixel spans ~10 arc minutes (/ 60 5.7)
• 12 meridians every 30 degrees (the sinusoidal map we're using is interrupted and has 12 gores)
  • around the equator, there is a degree every ~ 4.4 pixels (/ 1600.0 360)
  • this calculation needs to be done again, every time one moves up or down in the y direction, as the number of pixels with data has decreased ... thus as you move away from the equator in the y direction, the number of degrees longitude per pixel goes up
• calculating latitude and longitude degrees for every pixel
• while a pixel is square, the bounding area the pixel represents is approximated as a polygon
  • the top and bottom sides have different lengths
  • the sides are not parallel to each other, but rather are angled toward each other
  • thus the game world globe is not a sphere, but rather a polyhedron whose faces at the poles are three-sided polygons and everywhere else are four-sided parallelograms

Tiles in Redis:

• each pixel represents a tile
• each tile has a value for altitude, feature type (land, sea, ice), biome type
• each tile is represented as polygon
  • defined by three lat.lon coordinates at the poles (four, including the repeat of the first)
  • defined everywhere else by four lat,lon coordinates (five, including the repeat of the first)

Questions:

• how will tiles be used?
  • what tile am I in? (here's my lat/lon ... what tile contains that lat/lon?)
  • similarly, where is X?
  • how far away are X and Y? (GEODIST)
  • what else is around X? (GEORADIUS)
  • what tile is SW from here?
• to perform that last one ...
  • index ll and ur for all tiles?
  • GEORADIUS will be used, so maybe index the center location of each tile?
  • how to associate the coords of a tile's polygon corner coords with "a tile" in Redis?
• how will lat/lon be used?
  • should always be center of tile
  • sentient and object locations
  • distance between things
  • tracking travel distance

Notes on Redis GEO:

• Valid longitudes are from -180 to 180 degrees
• Valid latitudes are from -85.05112878 to 85.05112878 N
• Redis assumes that the Earth is a sphere; in the worst case distance errors may be as much as 0.5%

Tasks:

• Generate .bmp for deserts
• Add deserts layer to layers component
• Add desert? flag to tile
• Update tile processing to support the desert? flag

Or, another approach:

• wait for the rainfall map to be generated
• wait for the prevailing winds map to be generated
• look for low-rainfall areas, especially inland areas as well as the leeward side of high-altitude regions

Contributing factors:

• high temperatures
• low accumulated precipitation unit length per year
  • hyperarid deserts receive less than 25 mm
  • arid deserts receive between 25 and 200 mm
  • semiarid deserts between 200 and 500 mm
• low days/year of precipitation
• low humidity
• rate of evaporation
• moisture storage capacity of the ground

Ignore the following types of deserts:

• cold
• semiarid

Will support:

• hot
• coastal
• inland

The JVM is decidedly not known for its abilities in the rapid manipulation and analysis of image data. Perhaps a Golang, gRPC-based solution could be integrated into Hexagram30's suite ... and image service, maybe backed by memory-mapped image files (with more and larger images not being stored in memory, we'd be able to support a finer-grained player experience of the world ...).

Steps:

1. Get row
2. Check if the row is the first or last one and special-case those two
3. Count pixels in row
4. Calculate lon degrees per pixel
5. Calculate lat degrees per pixel
6. Calculate geodesic surfaces for each pixel
   1. At poles, use triangles
   2. Everywhere else, use rectangles
7. Calculate centers for each geodesic
   1. For geodesic triangles, approximate with half base and 2/3 from top
   2. For geodesic rectangles, halve each to find the distance to the center point of tile from any size of the tile
   3. Multiply by pixel index and lat/lon degrees to get 4 corner coordinates and the center tile coordinate

Note: this ticket is being superseded by hexagram30/raster#15 ...

Check out the following:

• https://medium.com/universe-factory/climate-modeling-101-4544e00a2ff2
• https://www.aoml.noaa.gov/phod/bin/phplib/popup_image.php?&pImgUrl=./currents.jpg&pPageUrl=http://www.aoml.noaa.gov/phod/soto/gsc/index.php&pSWidth=1280&pSHeight=1024&pTitle=Global%20Surface%20Currents
• https://www.weather.gov/jetstream/currents_max

If you take a look at hxgm30.map.tests.system.tile, you'll see what I mean. Creating a tile from band info requires not only the bands info (pixel-bands in the tests) but also a complex set of options. Each tests calculates most of these options based upon:

• the row in question (current-row)
• the column in question (row-item-index)
• the system configuration

There are several issues with these:

• why doesn't the API make all these options calculations itself? why does the user have to, for each call?
• what exactly are the variables and options used? They aren't very well documented ...
• what if we're writing code against a non-configured image size, format, or map projection? The API will fail spectacularly ...

Note that the initial intent for the existing API was simply as an ingest tool: parsing and correlating file data to be saved in a backend data store. However, now that the need has arisen to use this API more interactively or for scripting the generation of map features, it has become evident that the API in its current form is too limiting and difficult to use.

Dev tasks:

• Create a set of well-documented utility functions that do everything that's currently being done manually in each tile test ... create a bunch of unit tests for these
• Either refactor existing bands->tile function(s), or create new ones with different semantics for a better developer experience (if refactoring, we'll need to make lots of updates to the system tests)
• Create general-purpose functions that don't depend upon the system, but which can easily be used by system functions ... these can get unit tests
• Refactor system-based functions to have these new general-purpose functions do most of the work

Currently, we can tell a player that in a given 25 square kilometers of world space there is a river; by looking at surrounding pixels, we should be able to say if there are other rivers/tributaries that join it/split from it "near by"; but there's currently no way of telling a player that:

"To the North, the river is upstream, and to the West, the river is downstream; that there is a tributary to the East, coming from the hills, and that a gorge to the south causes the river to split into two (the second downstream branch being to the south)."

• How can we support the inclusion of land gradients, so that the above example would be possible?
• We currently have a global river overlay: can we use land gradient data to accurately and easily determine overall downstream for a river? (A local "reversal" of direction could be an indication of severe river bending.)
• We currently have elevation bitmaps, but general gradient behaviour is very tricky to calculate (and, in fact, we used an external application to generate rivers, lakes, water basins, etc.); is there a good way to do this? If so, does this functionality need to be moved into the image server project? (See #30)

This feature should support the following usage(s):

• High-level, low-to-medium detail textual descriptions:lein describe x y
• Low-level, high-detail: lein observe x y
• Everything known about the given pixel (i.e., using all map layers) should be provided in human-readable text
• Should the OBSERVE command include surrounding pixels?
• Or should there be a third, bird's-eye command?

This would be useful for the map service:

• Allow for a greater number of map layers without impacting memory consumption by Java process
• Allow for maps with large image resolutions (and thus provide players with data in a tighter physical locale, in-world)
• Support run-time modifications of the world
• Support faster access to image files
• Obviate the need to store image data in a database

Change BMP processing to this:

• http://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/formats/bmp/BmpImageParser.html

Then we'd also get TIFF support for free:

• org.apache.commons.imaging.formats.tiff
• GeoTIFF
• maybe layers too ...

Could be interesting.

Tasks:

• Generate .bmp for prairies
• Add prairies layer to layers component
• Add prairie? flag to tile
• Update tile processing to support the prairie? flag

With the creation of the raster service (see hexagram30/raster#4, etc.), the map service will be divesting of many of its current responsibilities. Lots of questions will arise as part of this, such as:

• What should map focus on?
• How useful will it be as a consumer of the raster service?
• Will it simply be a collection of raster service queries?
• Will it offer some sort of tracking capabilities for players, npc, etc.?
• Will it offer player-level location-based caching?