John Krogstie and I wrote an article describing the work on MAPQUAL, as well as the current work on integrated models, quality aspects of these and the case-study in the medical domain. This is my first published article – which I find very enjoyable:) Unfortunately, due to copyright issues I can’t publish the full-text here, however I dare to attach the abstract. The article will be published in Springer Lecture Notes in Business Information Processing (LNBIP) later this year – before summer.  Thanks to John Krogstie who is very supporting and collaborating throughout every aspects of my work!

Integrated Quality of Models and Quality of Maps

Alexander Nossum, John Krogstie

NTNU, Trondheim, Norway

Abstract.

Conceptual  modeling  traditionally  focuses  on  a  high  level  of
abstraction. Even if geographical aspects such as location is included in several
enterprise modeling  frameworks  [26],  it  is not  common  to  have  geographical
aspects  included  in  conceptual  models.  Cartography  is  the  science  of
visualizing  geographical  information  in maps.  Traditionally  the  field  has  not
included  conceptual  relationships  and  the  primary  focus  is  on  a  fairly  low
abstraction  level. Both  cartography  and  conceptual modeling  have  developed
guidelines  for  obtaining  high  quality  visualizations.  SEQUAL  is  a  quality
framework  developed  for  understanding  quality  in  conceptual  models  and
modeling languages. In cartography such counterparts are not common to find.
An  attempt  to  adapt  SEQUAL  in  the  context  of  cartographic maps  has  been
performed,  named MAPQUAL.  The  paper  presents MAPQUAL. Differences
between  quality  of  maps  and  quality  of  conceptual  models  are  highlighted,
pointing to guidelines for combined representations which are the current focus
of  our  work.  An  example  of  such  combined  use  is  presented  indicating  the
usefulness of a combined framework.

[26] = Zachman (1987)

Finally the promised follow-up to the post on data modelling in PostGIS. In this post I will cover how I populated the database using a graphical tool called uDig.

uDig is actually a (lightweight) GIS-tool by the same guys which make PostGIS. It supports for editing and analysis of spatial data. I actually don’t know that much about uDig, but it is easy to use, and fulfilled my needs:)

So. What I needed was to draw polygons from a floor plan. The floor plan was in .jpg format, so useless to “import” directly in the database. So I needed to georefer the floor plan “photo” and draw on top of it. Fairly similar to old map making techniques using aerial photographies to make “abstract” maps.

First the georeferencing. The actual coordinate system and extent of the floor plan wasn’t actually that important. It was nice if it started close to (0,0) and had some extent (and of course scaled 1:1).  Convinced (but not certain) that uDig could handle this I set of and tried to add a layer using Layer-Add .. files and selecting the .jpg file. However that resulted in some obscure error saying; “unrecognized service…” Well, off to Google. After some searching I found that for .jpg’s to be added in uDig, they first need to be georeferenced. To me that sounds a bit strange, as one might want to actually do just this in a GIS tool. So after some more searching I discovered that one could “manually” rough-georeference a .jpg using the world-file format, named .jgw – which in essence; locks one coordinate of the image to a geo-coordinate and defines the extent of the pixels on both axis. So I guessed somewhat on the parameters and came up with a .jgw. And add layer in uDig worked like a charm.

Floor map image in uDig

Secondly I needed to connect to my PostGIS database. This is very, very easy, as expected, since the two softwares are made by the same “team”. Just add layer -> PostGIS -> Type in credentials -> Select tables and you’re off:)

Add layers from a PostGIS database

Then it was time to edit/draw/insert data into the PostGIS database. This is fairly intuitive. I found that enabling “snapping” is very useful, and quite good implementation of this feature in uDig also. However, you need to enable it: “window->preferences->tool->edit tool->snap behaviour” Why hide this? Well, maybe not everyone are interested.. Anyway. Here you can set the snap behaviour and radius to whatever suits your need. I choose “all layers” and found it working surprisingly well on drawing the “route graph” which consists of several “connected” lines.

Enabling snapping in uDig

After some editing the data looked somewhat like this:

Inserted data

Of course the entities (i.e. rows in the DB) have other properties other than their geographic extent. And uDig provides an editor to enable direct editing of these properties. However…. This is where you really experience the short-comings of an open-source, “experimental” GIS-tool.. Not all editors are in place, such as BigDecimal. This is OK, as it is a minor thing and not that much of use. However, when the table has constraints, such as “NOT NULL”, then uDig just breaks, no errors, no confirms, no notices of what is going on. A bit disappointing. Additionally when editing, often the data isn’t commited properly to the database, and some error (again no messages) occurs. Resulting in the layer can’t be rendered and you need to remove it from uDig and add it from the database again. Luckily this isn’t a complex process though:) But a bit annoying. I ended up with using PgAdmin for the non-spatial data management and uDig solely for the spatial data. Which worked quite well despite the annoyancies.

My task was fairly non-complex, for larger tasks I wouldn’t rely on uDig – yet. However the simplicity of the tool is attracting! And for easy, lightweight tasks it is perfect:)

In my master thesis, one important attribute is the temporal nearness of concepts in the domain, such as moving persons and equipment. Special concerns for the case is that the geography is indoors in potentially complex buildings, such as large hospitals. The geography is considered to be known to the actors – assuming that the persons know where they are, where they are headed to and how to get there. This may argue that a floor map depicting where you are, your target and fastest route there is unnecessary – and I agree. However what may be of interest is to get information on how far away you are from your interest points and how far your interest points are from each other. For instance if you are 15 minutes away from your office, you have planned to meet your colleague there at 15 minutes, but your colleague is 20 minutes away. Provided by this information is 5 minutes that you can finish what you are doing, walk to your office, and still meet your colleague in time! (pretty lame example I know – working on my exemplifying skills:). Anyhow, the driving information is thus the temporal nearness. This is highly dependant on the geography in the context and it’s navigational abilities. Building generally has rooms with doors and corridors which in turns comprise and constrains the ability to move in that space (i.e. walking). My attempt at finding the temporal nearness comprise a spatial model of such a geography, a data structure for navigational abilities, implementation of this model in a spatial database (PostGIS) and calculation of the temporal nearness based on this. This blog post tries to explain just this. I plan to post a separate post on how to manage the data for this model - so watch out:)

Spatial model and data structure for indoor temporal nearness

Figure1: Spatial model and data structure