#322 Multiple <geo> tags in <location>

GREEN
closed-fixed
5
2013-01-06
2011-11-21
Martin Holmes
No

This ticket follows this discussion on TEI-L:
http://tei-l.970651.n3.nabble.com/Geographical-Coordinates-With-More-than-One-Datum-td3519925.html
The basic request was to be able to have multiple <geo> tags in a <location> element, but with each associated with a different coordinate system. However, the Guidelines say:

"All uses of geo within a document are required to use the same coordinate system, which is that defined by a geoDecl element supplied in the TEI Header. If no such element is supplied, the assumption is that the content of each geo element will be a pair of numbers separated by whitespace, to be interpreted as latitude followed by longitude according to the World Geodetic System."

No-one seems to know why this restriction exists. Syd B suggests that <geo> should be made a member of att.declaring, so that individual <geo> elements can be associated with distinct <geoDecl> elements in the header.

Discussion

1 2 > >> (Page 1 of 2)
  • Laurent Romary
    Laurent Romary
    2011-11-22

    In favour. There is a sense of magic behavior here imposed on the encoding that looks weird.

     
  • Syd Bauman
    Syd Bauman
    2011-11-23

    Well, either <geo> and <location> should be members of att.declaring, or <geoDecl> should not be a member of att.declarable. In the latter case, a different mechanism for associating a coordinate system with a particular <geo> element would have to be developed.

     
  • Martin Holmes
    Martin Holmes
    2011-11-23

    @Syd: I see the need for <geo> in att.declaring, but not for <location>; could you give a use-case for that?

     
  • BODARD Gabriel
    BODARD Gabriel
    2012-01-10

    This looks good to me. I have no opinion on <location>. I'm happy to make the change in the source if no one objects.

     
  • BODARD Gabriel
    BODARD Gabriel
    2012-01-10

    • milestone: --> 871213
     
  • BODARD Gabriel
    BODARD Gabriel
    2012-01-10

    This looks good to me. I have no opinion on <location>. I'm happy to make the change in the source if no one objects.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-01-12

    I suggest making the change for <geo> but not <location> since no one has provided a use case for it. If the change for <geo> is implemented and the ticket closed before Syd or someone else provides the use case, then that person could open a new ticket regarding <location>.

     
  • Martin Holmes
    Martin Holmes
    2012-01-12

    I'm going to contradict my previous message here, after some thought. I use multiple <geo>s in one <location> to specify an area, with each <geo> containing one lat-long coordinate outlining the shape. In this case, if I wanted to provide the location information using a different coordinate system, I'd want to add a new <location> element, not more <geo> elements in the same <location>. But if I were dealing with single points, I might well want to use one <location> and have multiple <geo>s with different coord systems.

    So I can see the case for both, and I suggest we go with that. Where <location> declares a coordinate system, any child <geo>s that don't override it should be assumed to inherit it.

     
  • BODARD Gabriel
    BODARD Gabriel
    2012-01-12

    @Martin, I'm not sure that's a correct use of <geo> though, is it? According to the element spec, <geo> defines "any expression of a set of geographic coordinates, representing a point, line, or area on the surface of the earth", so an appropriate way to define a polygon made up of multiple points would not be one <geo> per point, but a single geo containing an expression like:

    <geo>x y, x1 y1, x2 y2, x3 y3, ...</geo>

    And I don't think Scott's use-case--a single location that can be defined both by GPS and by OS coords--would be marked as two locations, but as two competing <geo>s within a single <location>.

    Having said that, I don't particularly object to making <location> part of att.declaring as well, if people have a use case for it. I can certainly imagine cases unlike that of GPS vs OS, where the two sets of coords really do define different kinds of location, rather than just two notations with identical referrent.

     
  • James Cummings
    James Cummings
    2012-01-12

    I can easily think of differing locations or systems of location for the same place. So would support making both declaring.

    JC

     
  • Martin Holmes
    Martin Holmes
    2012-01-12

    @Gabriel: it's arguable that I'm tag-abusing by using multiple <geo>s, but I would argue that I'm storing one point in each <geo> (which is perfectly legitimate), and collecting all those points together using <location> (also legitimate, otherwise why can <location> have multiple <geo> children?). I do it for each of processing, but it also seems neater and cleaner to me than stringing a whole bunch of coords together in one <geo>.

     
  • Lou Burnard
    Lou Burnard
    2012-01-12

    From memory, the reason for the current state of affairs is that no-one could see any good reason for storing coordinate information using different coordinate systems within a single document, since the data was always going to be created afresh rather than encoded from some other source. Similar arguments were advanced wrt calendar normalisation. As we have now added support for normalised dates using different systems, I suppose that counts as a precedent. I entirely agree with Syd's original comment -- that if geoDecl is a member of att.declarable, then geo should be a member of declaring: in fact I think that's a simple corrigible bug. I am not persuaded by the arguments for making <location> declaring however, nor for permitting multiple <location>s. I think Martin's usage is unnecessarily inconsistent with the Guidelines specification for <geo>. <location> is explicitly defined as defining its parent <place>, and should therefore be thought of as a unique identifier.

     
  • Martin Holmes
    Martin Holmes
    2012-01-12

    @Lou: I think you're right about my usage, but every example in the Guidelines shows only a point, with the exception of this one, which chooses to use a different namespace to represent an area:

    <geo>
    <gml:Polygon>
    <gml:exterior>
    <gml:LinearRing> 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8 -109.2
    45.256 -110.45 </gml:LinearRing></gml:exterior></gml:Polygon>
    </geo>

    In your opinion, why does <location> permit multiple <geo>s?

     
  • Martin Holmes
    Martin Holmes
    2012-01-12

    I've discovered why I decided to use multiple <geo> tags: the note on <geo> says:

    "All uses of geo within a document are required to use the same coordinate system, which is that defined by a geoDecl element supplied in the TEI Header. If no such element is supplied, the assumption is that the content of each geo element will be a pair of numbers separated by whitespace, to be interpreted as latitude followed by longitude according to the World Geodetic System."

    I interpreted this to mean that if I'm not supplying a <geoDecl> element, I can only put one lat-long in each <geo>, so that's what I did. When we rewrite this, I suggest that it be clarified, assuming that's not what was intended.

     
  • James Cummings
    James Cummings
    2012-01-13

    Hi all,

    If I have multiple <geo>s inside a single <location> then are these alternate forms of representation of this? (i.e. a single GPS location in the middle of the area that google maps might give you when you type in a placename vs a polygon tracing the administrative boundary of the location.

    If a place has differing boundaries (for example at different times) then these would be different <location> elements, and the justification for why it claims att.datable and att.type membership. Multiple locations for a single place are really necessary since places move.

    But none of these argue for att.declaring for <location>, and if <geo> is a member I don't really see why <location> needs to be one. (Completely contradicting my initial gut reaction to this.)

    -James

     
  • BODARD Gabriel
    BODARD Gabriel
    2012-01-13

    I've added <geo> to att.declaring, pending discussion of <location>, about which I have no strong feelings.

    Now that I look at it, I'm not clear exactly what we do want to say about the content/format of <geo>. As Martin says, we obviously want to get rid of the note as written, which says:

    1. all <geo> in a document need to use the same coordinate system;

    2. in absence of <geoDecl>, this is assumed to be a space-delimited pair of coords (lat followed by long) "according to the World Geodetic System."

    The first part obviously needs to go; do we need to think some more about the format we want to encourage as the default? It's true that a coordinate pair will be the most common content, but what do we want to recommend for people who want, like Martin, to represent a polygon or polyline?

    I was thinking that a useful rule might be to follow an existing standard like gml:posList, but that expects coordinate pairs to be comma-delimited, and lines/polygons to be made up of a space-delimited list of such pairs. This is the opposite of what we seem to suggest now, and would therefore break a lot of people's usage.

    Any other suggestions?

    (Final question: do we also want to give some guidance under <geoDecl> about how to define more than one datum and refer back to them?)

     
  • Martin Holmes
    Martin Holmes
    2012-01-13

    @James: My argument for having <location> in att.declaring is that, if you have multiple <geo>s in a single <location> (for whatever reason), and they all use the same coordinate system, it's more effective to declare that on <location> than to have to declare it on every child <geo>.

     
  • Lou Burnard
    Lou Burnard
    2012-03-18

    The restriction to a single geoDecl was one proposed by the original work group, if I remember correctly, sort of by analogy with the decision to use only ISO or W3C times within a document.

    I cannot think of any good reason for having multiple <geo>s inside a single <location>, unless it's because you want to use different coordinate systems for them. A <location> is *defined* by its coordinates surely?

     
  • Lou Burnard
    Lou Burnard
    2012-03-18

    I'm changing this to amber, as we seem to disagree about what needs doing, if anything.

     
  • Lou Burnard
    Lou Burnard
    2012-03-18

    • milestone: 871213 --> 871214
     
  • Martin Holmes
    Martin Holmes
    2012-03-18

    You can perfectly well have five competing coordinates for (e.g.) Camelot. It's a single location, but different people think it's in different places.

     
  • James Cummings
    James Cummings
    2012-04-13

    Martin,

    I think I disagree. If you have 5 competing coordinates for Camelot, then you have 5 locations. Let's say we didn't have <geo> but just an address-like description using <placename>, <country>, <region>, etc. (As per the examples on the location reference page in fact).

    You wouldn't say:
    <location>
    <placename>Winchester</placename>
    <region>Hampshire</region>
    <placename>Cadbury Castle</placename>
    <region>Somerset</region>
    </location>

    You'd say:
    <location>
    <placename>Winchester</placename>
    <region>Hampshire</region>
    </location>
    <location>
    <placename>Cadbury Castle</placename>
    <region>Somerset</region>
    </location>

    That reads a lot more clearly to me at least. And if that is what makes sense whith placename and region, then the same must hold true for <geo>

    -James

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-04-16

    Council decided to remove phrase saying that all uses of geo are required to use the same coordinate system. Give an example using more than one coordinate system (through the document, preferrably, provided simply for ease of processing). Sebastian will handle with input from Kevin and Gabby! Note that element definition of geoDecl says it's explained in chapter 2, but it's not actually there.

     
  • Lou Burnard
    Lou Burnard
    2012-06-17

    • assigned_to: nobody --> rahtz
     
  • BODARD Gabriel
    BODARD Gabriel
    2012-06-18

    Re multiple geos in one location: I often record multiple sets of coordinates for one place, usually in the same coordinate scheme, not because they're different opinions about where the place is, but just because the provenance of the coordinates (and hence the reliability, granularity, etc.) are different, and I want to record them all. So one might be my cellphone GPS, one might be an archaeologist's report of GPS, but with unknown hardware, another coordinates extrapolated from Google Earth. I don't think these are three different locations (it's both the same place and the same location being recorded) just different sets of coords.

    (Not quite the same as Martin's example, but I think it supports the markup he is arguing for, and not James's objection to it.)

     
1 2 > >> (Page 1 of 2)