Myths on Maps

I've spent most of the last few days getting data in to the DB.
The DB now contains as many of the Characters, Events, Places and Citations as I can find. I've also populated relationship tables with as much of the relationship data as I can use. In a few cases (e.g. the EventsToCharRels table) I have data that includes generational IDs that I am unable to easily handle. I'll have to leave that to the data proofer.

I think I'm ready to start writing some PHP.

A couple of small thoughts:

In the end, a search that would traditionally be rendered as, say, an unordered list, could be directly rendered to the map. A KML file is th result of a search, and it is passed to the page as a layer.
Problems with this: if you search for Apollodorus you'll get a zillion hits. I need to put a throttle on the returns (if there are more than 50 hits you're encouraged to focus your search a little).

Generated KML files will have GIS bounds that can be extracted and used to set the extent of the rendered map (read: zoom level). This would mean that the map zooms automatically to a level that is suitable for the results of your search.

Worked part of the day on finalizing the db structure and getting used to the adaptive db code. Martin has abstraction in mind, which will make most of this obsolete, but until then, this is how to make the adaptive db edit your db.

You need to edit 7 files to get this working:
connect.php
has the connection info for accessing your db

enter.php
In span id="tabInstructions" make sure to create/edit the nested span ids and onclick events to reflect the tabs you want to display
Span ids need to be set, but naming is not important, however, the onclick event needs to know which tab to display, so keeping the span id name in line with the tab name is a good idea. The onclick needs to have the name of tab (an arbitrary 'alias'), which is used/named in save_rec.php, local_classes.php, get_rec.php, get_reclist.php and del_rec.php. It is also used (although only for clarity) in the div near the end of enter.php, like this: <div id="pnlGrsE2E" class="tabPanel">

In the php that begins after this:
<div id="pnlGroups" class="tabPanel">
the getRecordList function takes 3 args: tableName, number of columns to display, and number of records to display

local_classes.php is the meat and potatoes file
You can choose from several field types:
* MdhIntField: an integer field. Takes fieldName,display name and an (?) integer
* MdhStrLookupField: custom widget which displays previously entered values like a select box, but allows a new entry. Takes fieldName, display name, some always empty field, tableName, fieldName, maxLength (tie this to the actual maxlength in the DB), true/false for whether this widget is to offer sortability in the gui.
* MdhStrSelectField: select box constructor which takes fieldName, display name, some integer(?), tableName, fieldName, fieldName, true/false, true/false. The second tableName/fieldName declarations are the lookups to get actual values to display instead of ints stored in the inital table.
* MdhTextField: large text field (memo-type widget), taking fieldName, display name, empty slot(?), maxLength
* MdhStrField: regular text field (standard text field widget), taking fieldName, display name, empty slot(?), maxLength
* MdhLatLongField: a special field for latitude and longitude. This has a special javascript validator to determine if it's a legal lat/lon

get_rec.php, del_rec.php, save_rec.php
All contain a switch with tableNames and 'aliases'. You need to add a new case for each table in use.

get_reclist.php
Contains a switch using tableNames, fieldNames and 'aliases'. Edit the orderByField to change sorting behaviour. Add a new case for each panel you need to add.

The creation of the MySQL schema has been difficult, due mostly to the requirement to include multiple authors, each of whom might tell the *same* story in different ways (different characters, places etc.). EVERYTHING needs a 'related-to' table and a relationship-to-citation table. Foreign Keys will be crucial to maintaining data integrity, and it's been tough to learn it at the same time that I'm trying to understand the basic concepts. It's hard, but I *think* I've discovered something peculiar about MySQL**:

If you create a structure with constraints and no data, then try to add data, MySQL barfs. If you create your basic schema and insert a smidgen of data in to the tables that will have constraints, you can then go back and create your constraints and add new data in the constrained fields quite happily.

Note on PHPmyAdmin: constrained fields will show a dropdown list that looks similar to this:
-3
-2
-1
1-
2-
3-
As far as I can tell there is no difference between -3 and 3-, but I'm only using a dump file to view the data, and I don't really understand this stuff too well right now.

**this appears to be a reported bug that has been fixed in 5.1.13 (we're running 5.0.51) - good job we're rebuilding.

As a simple test of the portability of the AdaptiveDB code, I ported it to work with Greg's initial DB model for MoM. Took a couple of hours, but it works fine. These are some key points to bear in mind, and requirements for future features:

• There are Latitude and Longitude fields, so I created a new field type for those, based on the date field, but linking to a different client-side JS validation routine, based on a regex. This routine is currently simplistic, and doesn't differentiate between lat and long, but it'll do for now.
• There are at least two instances of many-to-one relationships tracked through secondary tables. Currently, the editing environment allows you to work on those secondary tables directly, but ideally there should be a new db field type in the AdaptiveDB code which models this kind of thing. It could be like a MdhStrSelect field, but handle multiple fields in the other table, and also write them to the other table. Once I've written this kind of field, assuming it's smooth sailing, the AdaptiveDB code will be really quite powerful.
• There's a lot of pointless repetition in the AdaptiveDB code, because it grew by accretion. There needs to be another component of local_classes.db which is effectively a lookup table for all the record classes in the file. The ancillary PHP files such as save_rec.php, del_rec.php, get_rec.php and get_reclist.php should make a call to this lookup table to get the classnames they need to interpret incoming data. That would localize all project-specific code to local_classes.db.

I now have a PHP development version of MoM on line: http://hcmc.uvic.ca/grs/map/index-dev.php
Not much to see aside from the new data, which is awesome. I got it from http://maps-for-free.com/ and am unzipping all 17 million images in to a web dir so we can use it where we need it. It isn't served via a service per se, it uses a primitive layer method called XYZ, which uses regex to find the tile needed - like this:

var mff_relief = new OpenLayers.Layer.XYZ(
	"Terrain",
	"http://hcmc.uvic.ca/srtm_data/layers/relief/z${z}/row${y}/${z}_${x}-${y}.jpg",
	{buffer: 0,sphericalMercator: true,numZoomLevels: 11}
);

The new data requires I use spherical mercator projection, which is fine except that my position marker is now in UTM (metres) instead of the usual lat/lon. There is a conversion method, but I haven't pursued this very far yet.
Next up is the sql...

I now have geowebcache acting as a proxy/cache for map tiles. The main grs map page http://hcmc.uvic.ca/grs/map/ will now use the local js and lettuce-based geowebcache to create a map. It'll be a bit slow at first as it builds its tile cache.

Discussed a number of practical issues, like what happens when users click on something, what kind of data will/will not be used. The more we look at it, the more it looks like a RDBS setup than XML. Stew's impression in a previous post is bang on, and I'll start on a SQL schema based on his post next week.

I've now got a page http://hcmc.uvic.ca/grs/map/ that can dynamically create and load a layer from a KML file. Right now the data is all static (hand-made KML files), but the tech (all JS)should work work in any environment.

I've been trying to get this working with a Google base layer, but most commercial providers use a Spherical Mercator projection, which uses X/Y coordinates (in metres for the most part); my system uses lat/lon. The maps that I'm caching (using GeoWebCache) are EPSG:4326 - read NOT Spherical Mercator, meaning that dots on my vector layer representing cities are in the ocean when one switches to a Google layer. While this can be overcome by not using a Google layer, I cannot achieve the same resolution with my sources so if you stick with My BMNG or Modis layer, the image becomes unusable very quickly. It is apparently possible to have openlayers do the math on the fly, but I'm still trying to figure it out. Docs here: http://docs.openlayers.org/library/spherical_mercator.html

At this meeting we discussed what information what information will be presented to the user on the map, and how that information will be presented, especially what the first image presented will be. The first may be an image of Greece with a dot for every location contained it the database. Clicking on a city would bring up a list of generic searches related to that city (e.g. characters, events, authors).

We also discussed genealogical information. It was decided that when a character is selected, we would present only directly related family members. Directly related family members are parents, children, siblings and spouses. It should be possible to trace a genealogy by going from family member to family member, and it may be desirable that some trail be left on the map of the path taken.

LM and I are to meet next week to create a document describing 1)what the initial map should look like 2) what searches/information should come up when a city is clicked 3) possibly, what the information might look like at the next stage after that 4)how family information should be presented on a map.