The GIS and the Front End

What is a geographic information system (or GIS)?   In its simplest form a GIS is a software package meant to facilitate the creation and display of maps along with analysis and display of any data that includes lat/lon pairs. 

There are some critical components in a GIS.  A database, for example, along with a ‘front-end’.  O.k. so what is a ‘front end’?  A ‘front-end’ is a software package that interfaces to a database and makes it possible to retrieve data and convert it into a map.  The second thing a ‘front-end’ must do is allow the user to specify geographical points that then get stored in the database for later retrieval/mapping.  In other words a front-end acts to gather and store data in a DB and it also gets data from the DB and displays it as a map or as tables. That’s really all there is to it.

And a GIS can be surprisingly simple.  Google Earth makes a respectable ‘front-end’ but you need to use it in conjunction with a database in order to have anything like full ‘GIS’ functionality. So that although the two parts, Google Earth and The Database, are separate and not automatically interconnecting, you can still use them together even though you store what you retrieve from the database as an intermediate flat file before you then import it into Google Earth.  It looks like this:

I’ve numbered the arcs here for easy reference.  In step 1 we get a lat/lon pair from Google Earth and we attach it to a place name and id with some .sql query like this:

insert into site (

place_key,

name,

lat,

lon,

region)

values (

‘C9999’,

‘Tholos’,

36.7654,

22.4536,

‘Messenia’);

In step 2 we take that .sql statement and enter it into the database.

We repeat steps 1 and 2 as often as we need to in order to generate a database of place marks.  When that’s done we have a table (the ‘site’ table in this case) which holds our data and which was derived from Google Earth. 

Later we want to come back and display the site table on a map.  In step 3 we execute the following query in the database:

select * from site;

…And we save the result as a comma-separated file (or .csv).  A good database, such as MySQL, will allow you to do this. 

In step 4 we import the .csv into Google Earth using GE’s ‘import’ feature (not the ‘open’ feature).  Importing into Google Earth is described here.

And the result is that you now have your data displayed on a map.  Of course you can modify the site table in the meantime, amplify it from different sources, etc., etc.

Once the data is displayed in Google Earth you can also save it as a .kml (.kmz is a .kml in zip-file form).  The .kml is a very useful file type since most GIS products support it.  That deserves a modified picture:

Here, in Step 5, I show the Google Earth capability of exporting either .kml or .kmz files.

And although this method seems a little clunky (because of the hand derivation of .sql statements in step 1 or the intermediate .csv file in steps 3-4) it’s still a perfectly reasonable way to work and, in fact, all the Mycenaean Atlas Project so far, thousands of points, has been implemented in just this way.    Why does this work?  It works because the work of finding points can be very much greater than the relatively trivial operations of hand-entering them into a database.  As long as a project is small or the data entry is a small part of the total cost we don’t need anything more elaborate.

Another method of extracting information from the database (besides extracting flat files from it) is to write custom software for that purpose.  For example, in the Mycenaean Atlas Project the database contains lots of material that you wouldn’t ordinarily display on a map, like bibliographic information.  And yet the bibliographic material supports the rest of the database; it is the warrant, in a sense, for the data’s accuracy.  For that type of material you’d want to generate, not a map, but a report.  For that purpose you could just use sql:

select * from fnb where pk = ‘C237’;   // this query would return bibliographic citations for site ‘C237’.

And sql can be made very elaborate and, ordinarily, .sql queries can work for this purpose perfectly well.

But let’s say that you want to dump, in a nicely formatted form (not just a table), all the bibliographic material and show its connections to the rest of the DB.  For that purpose simple sql might not do so well.  

 For writing a fancy report you need to write a program.  I expand our diagram to show that possibility.

Here I show a software interface connecting to the database and generating (in arc 6) a text report of some kind.  There are several good software interpreters that make connecting to the DB simple.  The PHP language is a reasonable choice.  It is very widely used in Internet applications to serve a site’s online database.  In fact, if we were to put the Mycenaean Atlas Project online the Text Report attached to arc 6 would actually consist of .html pages.  To download your free, widely-used, standard version of PHP just click here. 

The Mycenaean Atlas Project actually does use a couple of self-developed programs in PHP in order to generate full reports of nearly the entire contents of the database.  (These reports are in .pdf form, and they're yours for the asking).  The first is a complete report on all the Bronze Age sites; the second is a complete dump of the Features table.  (The Features table consists of non-Bronze Age sites which are mentioned in the gazetteer and other literature and which you need to know about in order to make sense of that literature.  ‘Features’ include towns, signs, churches, monasteries, regions, chapels, streams, bridges, etc. etc.)  

By way of parenthesis there is a .php class that allows you to build .pdfs directly.  Find it described here.  

What I've shown so far is a little over-elaborate. 

To simplify things we can get ourselves a front-end that can interface directly to the database and by eliminating the hand written .sql statements as well as the intermediate .csv file.  After all, once we’ve finished with hand-created .sql files and db-generated .csv files we don’t want them hanging around.  The Truth Model is in the Database and in the Database only.  The .sql and .csv files must be trashed once they’re used so as not to lead to confusion.

What front-end interfaces directly to the DB?

A correspondent of mine from Cambridge, England, shares that he is working on a project to map Bronze Age burial sites using QGIS as his Geographic Information System.

What is QGIS?  QGIS is a genuine, full-featured GIS that replaces nearly all the complicated stuff I’ve presented so far.  I’ll discuss it soon in a separate blog post.

~~~~~~~~~~~~~~~~

Anyone who would like to have a copy of the MAP database can send an e-mail to bobconsoli 'at' gmail.com or leave a comment on any of my posts.  To run the MAP database requires a SQL server running on your desktop computer.   MySQL is such a server and it is powerful, industry-standard, and free.  

I can and will make .kml or .kmz files, which can be opened directly in Google Earth, available to those who would like them.  

I can also create .csv files for people who would like to import Mycenaean Atlas Project data into Google Earth but would like it in tabular form.

Those who do not have a SQL server but would like the full database in .pdf form can have that for the asking.

If you like these posts then please follow me on Twitter (Squinchpix) or on Google+   (Robert Consoli)

Facebook?  Sorry.I.just.can't.