On May 31, 2001, the Yahoo team sent out an email announcing the first release of PostGIS.

PostGIS is closely related to Refractions Research, a consulting firm founded by original author Paul Ramsey in the 1990s. His first cash came from the British Columbia government, which for its own reasons didn’t want to use ESRI’s software, so his company built up skills and experience that most “GIS companies” didn’t have.

They were better at databases and FMes, starting with Perl and eventually becoming Java. Their original product, now obsolete, was called Facet and was the core of their business for the first four years or so. It was a key part of the government’s mission to write analytical programs that could analyze spatial data and export tables and maps.

Given the computing power of the era, they had to use multiple Sun workstations to run the calculations across the province and then put the results into what was then PostgreSQL.

Importing fragmented spatial data as bloBs into PostgreSQL was the inspiration for PostGIS. Obviously, they already had the foundation of an interactive real-time analysis engine. If they could go one step further and do more with these bloBs than simply store BLOB field values, That’s even more interesting.

Maybe we should make a spatial database

If you look at the spatial database in 2000, you’ll find these:

  • Oracle 8I spatial data options
  • OpenGIS Simple Features for SQL specification

And then that’s it.

In the end, they took two measures, ten to one.

As a first step, the provincial government is expected to hire a consulting firm that specializes in Oracle space functions. The provincial government actually wants to standardize on Oracle space functionality, but has made little progress after several attempts.

Oracle at the time did not see GIS as a universal requirement, seeing GIS as still a special field and seeing no use for “spatial databases”.

Figure below: Spatial data functionality in Oracle at the time.

Maybe that’s a good thing.

The second measure is to explore whether the spatial data model described in the OpenGIS Simple Features for SQL specification can be implemented. In addition to the description of spatial data types and elements, the specification describes how to store spatial data in tables.

The storage scheme is as follows:

Scheme 1A: Each element decomposed its coordinate components, namely x, y, z, etc., and stored in the row and column of the ordinary relational data table.

Scheme 1B: Store “binary Large Objects (BLOBs)”

Plan 2: Save “geometry type”

Having already worked with PostgreSQL, they tested the theory of how to store spatial data in a database and extract it efficiently to create a PostgresQl-powered spatial data viewer.

For the viewer implementation, they used JShape (a Java applet) library to implement and experiment, along with some small web applications for customers. It is interesting because it can connect to dynamic databases rather than static files.

All the development work was done on the Sun Ultra 10 desktop, which I bought with a $10,000 loan when I started the company. At the time, much of their revenue came from Facet software, which ran only on Sun’s hardware platform.

For plan 1A, you cut up the geometry into a relational table and then you take it out and you reconstruct the geometry, which is incredibly slow and unusable;

Scheme 1B, which uses PostgreSQL bloBS to store large objects, is much faster, but still not satisfactory, because there is no way to add spatial indexes to spatial data.

breakthrough

They almost stopped development because plan 1A/B was bad, and they even went through the PostgreSQL documentation.

The big guy on the team, Dave Blasby, who had a background in computer science (most of the team had a background in math and physics), wasn’t afraid of low-level languages. He went up to PostgreSQL and looked at the source code and how to contribute it, and said, “Give me a minute, I do a custom type to store space data “rhetoric.

Dave took a few days, and it worked.

When Dave came up with a rough idea, they hooked up the cock program to the applet, and it just took off.

Even if you load a large enough table, scale the data, and draw a map, it’s fast. What used to be an XWindows screen on a Unix workstation now runs on an applet on a normal PC.

The team has had a good experience with PostgreSQL, but PostgreSQL extensions don’t have a commercial ecosystem, so the best thing to do is to leave PostGIS open and see if there’s any traction.

There were, like, six people Refractions at the time (I don’t remember exactly), many of whom contributed to the first Refractions.

  • Dave Blasby continued to refine the code, adding some interesting features;
  • Jeff Lounsbury, the only C language person, was responsible for converting SHP files into SQL to make it easier to load existing spatial data files;
  • Paul Ramsey is responsible for makefiles, CVS versioning, writing documentation, and preparing for open source.
  • Graeme Leeming and Phil Kayal, his business partners, connived in this open-source behavior. Chris Hodgson, a very smart developer, was busy at first, but later appeared in the commit log.

release

Finally, on May 31, 2001, Dave unveiled PostGIS 0.1, which you can still download if you want.

The first GitHub commit tag is still intact, the PostGIS 0.1 commit, and you can even see the plain text log.

The first version has a GEOMETRY type that uses the PostgreSQL GIST API as a spatial index and comes with the following functions:

  • npoints(GEOMETRY)
  • nrings(GEOMETRY)
  • mem_size(GEOMETRY)
  • numb_sub_objs(GEOMETRY)
  • summary(GEOMETRY)
  • length3d(GEOMETRY)
  • length2d(GEOMETRY)
  • area2d(GEOMETRY)
  • perimeter3d(GEOMETRY)
  • perimeter2d(GEOMETRY)
  • truly_inside(GEOMETRY, GEOMETRY)

Truly_inside () is the only analytic function that simply calculates whether a point is inside a polygon.

Looking back at those early emails from 2001, IT’s amazing how quickly PostGIS has been able to integrate various open-source geospatial efforts over the past 20 years.

Frank Warmerdam of GDAL and Daniel Morissette of MapServer posted posts within the first month of PostGIS’s release, and Java GeoTools/GeoServer developers quickly emerged.

The demand for open source spatial databases is as large as you can imagine. They just showed up at the right time.

How are they now

  • Graeme, Phil, Jeff and Chris are still working on geospatial consulting services at Refractions Research
  • Dave spent his first few years maintaining and improving PostGIS, leaving Refractions for other work, but still working on open geospatial aspects, mainly GeoServer and other Java projects
  • The author himself, Paul Ramsey, saw a bright future for PostGIS, but geographic consulting didn’t excite him. In 2008, he left his Refractions and learned enough C to join the PostGIS development community as a contributor. Has been working on this since then and is currently an executive geospatial engineer at Crunchy Data

.

The original start-up from PostGIS, is also the core contributors Paul Ramsey in May 2021 blog blog. Cleverelephant. Ca / 2021/05 / pos…

After learning this history, I was shocked and surprised by the achievements of the continuous development of the open source GIS community in the world in the past 20 years. At the same time, WHAT I admire more is that these uncles could do such meaningful things at the beginning of the new millennium, perhaps at the same age as I do now. Today, it’s fair to say that the open source GIS community was groundbreaking.

GIS is heavy on data and concept, which is naturally suitable for the backend. At that time, no database manufacturer took spatial data as a vegetable basket. At most, it was simple functions such as storing a very simple coordinate, line and polygon.

Smile. Isn’t that true of most teams in the current domestic running business?

But 20 years ago, they realized that and opened source.

Up to now, PostGIS is still one of the open source GIS databases. Although MySQL and other databases have simple spatial functions, compared with PostGIS’s integration of multiple mature libraries in the world of graphics, it can only be said that it is not enough “GIS” flavor, like eating fried dough tiao without soybean milk for breakfast, which is missing something.

Now PostGIS has come to 3.x, the company has backed it, and the GitHub source code is still being updated at a regular pace, making it a good learning experience.

I hope I can enlighten myself by reading these materials, and if I can enlighten my readers, it will be my pleasure.

Attached PostGIS structure definitions related to geometric types

First version

 typedef struct
 {
   double x,y,z;  //for lat/long x=long, y=lat
 } POINT3D;
 ​
 typedef struct
 {
   POINT3D LLB,URT; /* corner POINT3Ds on long diagonal */
 } BOX3D;
 ​
 typedef struct
 {
   int32 size;           // postgres variable-length type requirement
   int32 type;           // this type of geometry
   bool is3d;            // true if the points are 3d (only for output)
   BOX3D bvol;           // bounding volume of all the geo objects
   int32 nobjs;          // how many sub-objects in this object
   int32 objType[1];     // type of object
   int32 objOffset[1];   // offset (in bytes) into this structure where 
                         // the object is located
   char objData[1];      // store for actual objects
 } GEOMETRY;
 ​
 ​
 // ONLY FOR INDEXING
 typedef struct geomkey {
   int32 size; /* size in varlena terms */
   BOX key;
 } GEOMETRYKEY;
Copy the code

The latest version

Now, it’s located at github.com/postgis/pos… The liblwgeom/ liblwgeom.h.I. N file in the warehouse has a very different definition:

 /****************************************************************** * LWGEOM (any geometry type) * * Abstract type, note that 'type', 'bbox' and 'srid' are available in * all geometry variants. */
 typedef struct
 {
   GBOX *bbox;
   void *data;
   int32_t srid;
   lwflags_t flags;
   uint8_t type;
   char pad[1]; /* Padding to 24 bytes (unused) */
 }
 LWGEOM;
Copy the code