Geotagging in Ontopoly

We thought it might be interesting to show off one of the new features in 5.1.1: geotagging.

Let’s imagine that you are making a map of pubs, as some of us do. The geographical location of a pubs is a very important piece of information to attach to it, so let’s do that. We create two occurrence types, latitude and longitude, and give them the required PSIs. Once we’ve done that, the pub instance page looks like this:

Geotagging a pub #1

Note the little icon next to the latitude field. Clicking that will open a dialog window, as follows:

Geotagging dialog #1

If you now type in the address and click the “Search” button, and then zoom in, you see the following:

Geotagging a pub #2

This is the correct location, so we just click “Set position” at the bottom, and are done. Alternatively, you can click anywhere on the map to set a different position. After clicking “Set position” you come back to the topic, with the coordinates set, as shown below:

Geotagging a pub #2

5 thoughts on “Geotagging in Ontopoly”

  1. The geotagging support is a great feature of ontopoly. Maiana also supports geo information by default – but a bit differently. Whenever the value of an occurrence has the data type a link to a map is automatically generated.

    Examples are all topics of type report in the Afghanistan War Diary 2004 map ( or all occurrences of type coordinates in the toytm (, like the following information for Amsterdam:

    isa ;
    – : “Amsterdam” @;
    – : “Amsterdam” @;
    : “52.373056 ; 4.892222″^^

    In consequence it would be great to have an alignment between the Ontopoly and the Maiana solution – that each geo information generated in Ontopoly is automatically usable in Maiana.

  2. This is a good point. I guess the only question is how to do it. We now represent the position information differently, which makes this harder.

    Merging the occurrence types would be possible, except that you use one occurrence, and we use two.

    Similarly, for us to use the WGS 84 datatype would be possible, except that we use two occurrences, so the syntax is different.

    So, I think the key question here is whether this ought to be a single occurrence, or two. Having it as a single one is cleaner in some ways, because it avoids the possibility that someone provides only half a position. However, this makes it harder to use in presentation, because you have to parse the occurrence and split out the values. I decided on two separate occurrences because I did not want to have to do this parsing in the presentation layer.

    We use Google Maps coordinates, but fortunately, those turn out to be WGS 84 coordinates, so there is no problem there.


  3. This is a really nice development. My instinct is to store as two occurences, making it as easy as possible for users to do something with the values, either independently or togetther, although the values naturally come as a pair. This is reinforced by the possibility of wanting to use height data, which means a third occurence, which would be muuch more likely to be used without lat/lon. Having said that, GIS databases tend to store geometry in a single field, representing a point, polygon or line. But you are not trying to be a GIS database, so better to use the atomic form.

  4. Personally, I’d prefer three PSIs: lat, long and altitude. Altitude could be implemented in Ontopia using the Google Elevation API ( But I would like to see an explicit reference to the WGS84 reference datum in the docs of Ontopia.

    Agreeing on a common format is, in my opinion, not necessary but also not feasable. I think it is the responsibility of the topic map viewer to recognize the common PSI sets for geo information (which in practice might turn out to be a handful different ways). For my Subjects App (, I’d like to add support for the Ontopia and Maiana PSIs, equal or not, but also the W3C WGS84 lat/long vocabulary ( My personal topic maps with biological specimen observation data use even yet another format: they store geo positions in MGRS format, which, for some reason, is commonly used in the entomological community. So that’s one more format to support in the Subjects App.

  5. I’d be happy to ditch the Ontopia PSIs and use the geo lat/long URIs instead. I’d also be happy to add one for elevation, even though Ontopoly probably wouldn’t support it right away.

    I agree that if we do keep the Ontopia PSIs we should mention WGS 84.

    I think in general, the fewer formats we have, the better. Anything that helps us reduce the number is good in my book.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s