I left that startup soon after, but I heard that the backends for the GIS product really didn't have to be upgraded or revamped for years— PostGIS and GeoServer were just running solidly. Really a testament to the developers of those tools.
I've been making spatial apps for probably 8 years now and moved from Google maps and Leaflet towards vector maps and I don't think I'd ever go back.
When things get too large you can keep them in the mbtile file and serve them out with an express app.
I've done it in a severless environment which scales well but would get crazy expensive for any high use.
I used this article myself to learn:
There are a couple more articles at the bottom of the awesome vector tiles I linked to before but haven't read them myself.
Reading through the list is good as well because it's a good overview of the whole ecosystem.
This article also shows a simple way to dynamically serve vector tiles directly from PostGIS. I didn't realise you could do it without the middlewear, time to look into doing it this way!
I am currently interested in it because I want to feed tiles to a GAN to automatically generate maps of an imaginary earth..
For the reprojection, tile cutting, and overview building in gdal, see https://gdal.org/programs/gdal2tiles.html You can also implement it yourself fairly easily if gdal2tiles.py doesn't have the features you need. The files and directory structure it outputs you can slap into into a static webserver and visualize directly with something like leaflet.
As far as where to get data, that's a whole topic unto itself, but you can start with things like https://earthexplorer.usgs.gov/ for Landsat or https://datagateway.nrcs.usda.gov/ for NAIP or https://scihub.copernicus.eu/ for Sentinel.
What tools would work best / support that workflow?
In your case, all of the full libraries like proj4 already support it. What you're describing is a custom ellipsoid and datum. Plug that in, and you're good to go. You'll need to define the shape of your asteroid's equipotential surface through a reference ellipsoid dimensions and a datum that defines deviations from that ellipsoid. Making those is definitely non-trivial, but once you've got the datum grids made, the math is the same as it is for Earth.
Also note that the datum is _not_ the shape of the asteroid directly. It's the 3D shape of a surface that's "flat" gravitationally. In other words, it's the shape of sea level. It's something that depends on the density distribution of the body and it's really not easy to measure, though it is easy to predict if you know the density distribution a-priori.
The shape of the asteroid's surface is topography. That's independent of the coordinate system.
I would have stated this first.
You don't really need a equipotential surface or even vertical datum, unless you're trying to model potential energy, uphill and downhill, the flow of a river, or the gravity well. All of which are unlikely to be known or easily measurable on an astroid.
And if all you want to do is look at the geometry of a surface, you don't need, or even want to use a horizontal datum and projection. It will just overcomplicate the math.
Lat long or a similar polar (or elipsiodal) coordinate system using orthometric height from the origin (or an arbitrary "zero" datum height) will be much easier. Especially in the case of a body without existing coordinate systems or projections that need to be "tied-in."
On the other hand, there are cases where using the GPS style coordinate system makes more sense (which is just an x,y,z or x,y,H version of lat, long, height. Yes, at it's heart, GPS uses Cartesian x,y,z). This is especially true if you're not concerned with defining an ellipsoid, prime meridian or equator. (Especially true for shapes that might not rotate, or fit well to an elipsiod or sphere.)
The thing to remember is that coordinate systems and projections mainly exist to translate between the many different ways people have been mapping and measuring the Earth for hundreds or thousands of years. Sometimes there are good reasons for these different methods (shape, area, directional constraints), and sometimes it's advanced tech/ systems (SI vs Imperial, Clarke elipsiod vs Hayford , or convenience/locality (relating Rose line observations with those made in Greenwich), or national security (USA not wanting nuclear icbm targeting stolen by USSR to be useful/meaningful/etc).
I say that to say this: If you're doing everything from scratch, there's no need to complicate things. Stick to the simplest math that works for the projects demands. There's nothing wrong with spherical polar or xyz.
My point was more that the standard mapping tools allow non-Earth bodies just fine. E.g. here's a UTM-like projection for Mars using a simple ellipsoid in proj4: "+proj=tmerc +lat_0=0 +lon_0=0 +k=0.9996 +x_0=0 +y_0=0 +a=3396190 +b=3376200 +units=m +no_defs" You can happily define a simple sphere of the right general size and have things work correctly.
It's not overcomplicating the math to use existing libraries, it's avoiding rewriting a lot of fairly complex operations that are easy to get wrong.
You can use gdal, proj, org, et al quite well on other planets. It's a hell of a lot easier than writing everything from scratch. They're set up to do things like this.
Although admittedly I haven't kept up with the different capabilities for the last few years.
What method/format would even be used to generate points for an astroid? Radar? Lidar? Photogrammetry? From a "where do you start" perspective, knowing that would probably narrow down practical approaches...
Mapping frameworks need to support map APIs to render stuff, and some APIs such as Open Geospatial Consortium's WMS (OGC WMS) requires clients to specify coordinate systems.
Yes projections need to be specified... The datum and ellipsoid are part of the projection. No, you won't be able to pass your custom datum along to an external service and have it recognize it automatically. That doesn't change the fact that you can define it locally and have your local tools recognize it. proj4 et al will happily let you define custom ellipsoids and register a new datum and work with projections on that ellipsoid and datum. You can view that just fine in QGIS et al.
Also, WMS is pretty niche and not too widely used partly because it supports things like this use case and is therefore quite complex. I wouldn't bring WMS into this. However, if you want to, the projection specifications it uses _also allow for custom ellipsoids_. You can happily request things in a projection with a non Earth ellipsoid -- it's just a matter of whether the WMS server supports it.
Edit: used google maps for the display before they changed their licence. Haven’t updated to OSM yet...
For the front-end I usually use Leaflet with Mapbox (raster) tiles. I should switch to vector tiles but "@2x" raster tiles look good enough on HiDPI/Retina displays.
I'm also an heavy QGIS user. I've managed to convince IT to put it in our internal Software Center so users can install it in one click without needing to be admin. It's becoming quite successful internally ;-). Take this Esri!
However we still pay hundreds of k€ to Esri and nothing to QGIS. I've personnally donated a few euros but it's a really small amount compared to what we pay to Esri.
If I want to become a developer and sell the projects on your platform: How can I start?
What is proximate pricing schema?
One option is our cloud (pricing is on the page). https://www.omnisci.com/cloud . You can also spin us up from the AWS, Azure, or GCP marketplaces. If you need an on-prem option, feel free to reach out: firstname.lastname@example.org.
Alt. for java devs:
It seems that all redis handles is points.
How would you query from shapes with redis?
I would be interesting to read more about why a tool was used, also: what are the current limitations?
During the time, we've build a self service GIS SaaS product. In contrast with a layers based GIS tools, it supports a complex Data models as you know from BI tools.
If you are interested, try our free trial: https://www.clevermaps.io/free-trial
and documentation: https://clevermaps.atlassian.net/wiki/spaces/CDD/overview
- Is there any article talking about and path optimization including time constraint? I've done something homemade (a mix of bird flight distance and time to destination) it looks "okay" but I'm sure can be better.
I've just built a tool to calculate directions for long flights layover , but the Google Maps API Directions sometimes lack of those data (Tokyo/Singapore/Istanbul for example). Any recommendations appreciated!
You could use pgrouting for routing.
I'm actually a fan of the HERE Transit API. They've done the work of interfacing with a bunch of providers, and you can query their whole dataset with a REST API. Unfortunately it's proprietary and only free at small volumes. But I found it much easier to hook up than working directly with a transit agency.
That said, their coverage can be a bit random. For example, I ended up having to do direct GTFS-RT anyway because HERE doesn't seem to have real-time data for NYC subways.
0 - https://deck.gl
1 - https://deck.gl/#/examples/core-layers/geojson-layer-polygon...
As a tangent, deck.gl (first time I've looked at it) describes their 64-bit floating point computation as having "unparalleled accuracy". It is not possible to correctly compute some double precision geospatial relationships using double precision computation (it requires quad precision or greater to produce a correct double precision result) and other software systems, including in open source, do this correctly.
0 - https://deck.gl/#/examples/core-layers/geojson-layer-paths
2. By default, many of the deck.gl layers don't use 64-bit floats, they use 32-bit floats for lat/lng degrees, which supports many use cases for resolution and speed. In a WGS84 projection, with a base/meridian of (0°,0°), a point in northeast Russia represented by two IEEE754 32-bit floats (say: 70°N, 179°E) will be within roughly a meter of its original value (as per https://upload.wikimedia.org/wikipedia/commons/3/3f/IEEE754.... and as per the earth circumference is ~40M meters, 1° is at most at the equator ~ 40M/360 meters ~ 100 km, and a rounding error of 10^-5 on a float that's 10^2 means you'll be off by around a meter). The deck.gl layers allow you to provide your zero point, and you get 100x the resolution at 1 compared to 100 in the exponent+fraction format for floats (so pre-render your Δlat, Δlng in 64-bit float computations with standard 80-bit precision somewhere besides WebGL). If you have more than a 100 km x 100 km square for which you need sub-centimeter precision, computed at render-time, 32-bit floats aren't for you. Which brings me to speed: WebGL doesn't have 64-bit floats, or 64-bit ints, natively. You'll have to fudge the math in software in a shader, instead of the native add instructions on the GPU, and that is far slower.
If you do need higher precision with only 32-bit integers, you can cluster your points around many different base/meridian points instead of the single (0,0), and take advantage of increased float precision on smaller numbers.
Here’s a couple of options:
geocode.earth -> Worldwide coverage
geocod.io -> US/Canada only, but supports spreadsheets, data appends and batch geocoding
smartystreets.com -> Ideal for USPS address verification
Disclaimer: I’m the co-founder of Geocodio
Do you happen to have any estimates when things start to break down for you in PostGIS? My largest table of PostGIS 3D geometries (line strings) has ~800,000,000 entries and most bounding box queries are still very fast (<100ms).
I need to create a polygon of specified width based on an arbitrary GPS track (which can cross itself multiple times). Can anybody recommend a JS library which is capable of doing this?
Also leaflet.js and openlayers.js for web mapping.
(In full disclosure I did work as an Intern for CesiumGS)
Google's Operations Research Tools has implementations for some vehicle routing algorithms.