Index

Scope

from the very small to the very big lets say

from this https://upload.wikimedia.org/wikipedia/commons/5/50/Milky_way_map.png

to this 0

for version one we should look for an expandible system that is good from 1mm - 1 light year (or add a few zeros)

but why

In order for a single mapping application to be use it needs to be trustworth to userwes whether they are worried about the soller system, the galixy, this world,
or their country, home, city, backyard, hiking, flying, shiping, planting seeds in a field, planting grains of sand on the beach.

Maybe this is a bit extream but if somone wants to write their name in the lawn with single blades of grass. photograp it but then says no i want to make a feee map of my home.

who are we to say no your grass project is too small for our system.

or if a sintist wants to build an understanding of the galexy next door .. or this one ... or even just this system. who are we to say its not a good project and its crazy out of scope. ;)

anyway rant over.
+.........

How

let 1 = one metric meter

let c = parseInt(299792458) // m / s

let 1au = 149,597,870,700; // https://en.wikipedia.org/wiki/Astronomical_unit

let 1ls = c; // https://en.wikipedia.org/wiki/Light-second

let 1ly = 31557600*c

let 1 1 astronomical unit = 149,597,870,700 metres (by definition) = 149,597,870.7 kilometres (exactly) ≈ 92,955,807.2730 miles ≈ 499.004783836 light-seconds ≈ 1.58125074098×10−5 light-years ≈ 4.84813681113×10−6 parsecs

// aproximitly let a1pc = 206264.806247096 * au https://en.wikipedia.org/wiki/Parsec let apc2ly = (pc)=>{pc*3.261563777}; //prefer use of let aly2pc = ly=>{return parseFloat(ly)/3.261563777}

//**** kinda irelivent but note the a prefix for an approximation img_6.png

now we have got the basics of very big. curent sintific units break down above one au as we canot mesure

... lets leave details for later

Arbitrary proposal for FreeMap standards.

ditch parsec in favor of light years etc

{
  "prefixes": {
    "largerQuantities": [
      {"name": "quetta", "symbol": "Q", "factor": "1e+30"},
      {"name": "ronna", "symbol": "R", "factor": "1e+27"},
      {"name": "yotta", "symbol": "Y", "factor": "1e+24"},
      {"name": "zetta", "symbol": "Z", "factor": "1e+21"},
      {"name": "exa", "symbol": "E", "factor": "1e+18"},
      {"name": "peta", "symbol": "P", "factor": "1e+15"},
      {"name": "tera", "symbol": "T", "factor": "1e+12"},
      {"name": "giga", "symbol": "G", "factor": "1e+9"},
      {"name": "mega", "symbol": "M", "factor": "1e+6"},
      {"name": "kilo", "symbol": "k", "factor": "1e+3"}, // why not use a big K for consitancy
      {"name": "hecto", "symbol": "h", "factor": "1e+2"},// are you a canible no 
      {"name": "deka", "symbol": "da", "factor": "1e+1"} // deka somone for using deka
    ],
    "smallerQuantities": [
      {"name": "deci", "symbol": "d", "factor": "1e-1"},
      {"name": "centi", "symbol": "c", "factor": "1e-2"},
      {"name": "milli", "symbol": "m", "factor": "1e-3"},
      {"name": "micro", "symbol": "μ", "factor": "1e-6"},
      {"name": "nano", "symbol": "n", "factor": "1e-9"},
      {"name": "pico", "symbol": "p", "factor": "1e-12"},
      {"name": "femto", "symbol": "f", "factor": "1e-15"},
      {"name": "atto", "symbol": "a", "factor": "1e-18"},
      {"name": "zepto", "symbol": "z", "factor": "1e-21"},
      {"name": "yocto", "symbol": "y", "factor": "1e-24"},
      {"name": "ronto", "symbol": "r", "factor": "1e-27"},
      {"name": "quecto", "symbol": "q", "factor": "1e-30"}
    ]
  }
}
Todo review and define an endpoint for this

The proposed idea revolves around a universal parsing system that dynamically interprets and assigns numerical values to any given string representation of units, with an emphasis on the scalability and flexibility of the metric system. This system would not only recognize and apply standard SI prefixes to units (like meters, grams, and liters) but would also automatically generate appropriate prefixes for numeric values that fall outside the conventional SI range, thus ensuring accuracy and clarity in the representation of extremely large or small quantities. By dynamically calculating the prefix based on the power of ten, it would seamlessly integrate both known and arbitrary large or small scales, effectively transcending the limitations of predefined units and allowing for precise numerical expression across a vast range of magnitudes.

While this concept is largely theoretical and aims at a level of universality not yet fully realized in existing implementations, there are several projects and libraries that touch on aspects of this vision, albeit within more limited scopes:

  1. Units of Measurement API (JSR-385): Part of the Java Community Process, this API provides a way to handle units of measurement and their expression in Java, focusing on accuracy and precision across domains. Units of Measurement

  2. Quantities, Units, Dimensions, and Types (QUDT): QUDT catalogs and defines units of measure, data types, and other relevant properties in a structured format, aiming at enhancing data interoperability. QUDT.org

  3. GNU Units: A Unix/Linux command-line tool that converts between thousands of different units, including many scientific and historical units. It supports nonlinear conversions and can parse expressions. GNU Units

  4. NumPy and Pandas (Python): While not directly aimed at universal unit parsing, these libraries are powerful tools for numerical computing in Python, offering functions and methods to handle large, complex datasets with units and magnitudes that can be programmatically managed and converted. NumPy, Pandas

These implementations demonstrate the feasibility and utility of advanced unit parsing and representation systems, paving the way for future development toward more universal and adaptable solutions.

Ontology, in a broad sense, refers to a branch of philosophy that studies the nature of being, existence, or reality, as well as the basic categories of being and their relations. It seeks to understand concepts such as existence, objects and their properties, space and time, cause and effect, and possibility. Ontology deals with questions concerning what entities exist or can be said to exist, and how such entities can be grouped, related within a hierarchy, and subdivided according to similarities and differences.

FreeMap

todo look at fneom project for great example of geospaital don right for a company

cut to

a folder of deliverables a word doc and some pdfs maybe a spread sheet. and a web map with etc.. a pile of shit stuff .. or data.

how do we close the gap.

Problem: 2 user groups

colarary: People making the nice builtins website are professionals and are usually bad at the fancy pants marketing stuff ;)

Lets not lie the job is hard and any self respecting stuff mover wants a nice organised pile of stuff for them to select the nice stuff and polish it.

The stuff selector

- find all the stuff put it in a pile and filter the stuff to
    - find all the stuff you need
    - organize it
    - catalog it
    - find more if nessasary

The stuff polisher

-  take selected relivent stuff and make it look pretty
    - find nice stuff from the catalog
    - clean it (and recatalog) 
    - make nice shiny turd for the client 
    - deliver under budget and over value

Ok so now what

Make good ui ux lol see pioneer for pretty good POC ;)

Data interoperability is essential

values of FreeMap

Prior work