#541 Using `<zone>` for points and paths rather than shapes
I'm working on the encoding of a historical map, and finding that I really need to be able to define paths on the map surface, not just closed shapes. <zone> is really constrained so that you cannot use it for paths; the @points attribute must have more than two points, so a straight line from one point to another cannot be captured with it, and the older @ulx, @uly and friends are intended to define a bounding rectangle.
I think the ability to encode both points and paths is a perfectly simple and reasonable requirement, so I'd like to propose several possible approaches:
-
The
<zone>element could be designated the appropriate way to do this, and the current constraint on @points removed so that it can contain one or two points only. The definition of @points would have to be updated, removing an existing current ambiguity: at the moment, we don't say whether the initial coordinate needs to be repeated to close the shape. The new definition would say that if the initial coordinate is repeated at the end, the result is a closed shape, while if it is not, the result is a path. -
The
<zone>element could be provided with two additional attributes, one of which is @point (taking a single coordinate) and the other is @path (taking a sequence of two or more coordinates, which are understood not to be closed to form a shape). -
One or two new elements might be created alongside
<zone>:<point>and<path>. The latter could inherit @points, but with a different constraint, so that two coordinates would be allowed, and the former would need a different attribute (perhaps @coords).
I prefer the first solution myself, because it's simpler; the only real objection I see is that it stretches what some people might see as the actual meaning of the word "zone",
Discussion
I feel ambivalent about this. I can see the attraction of marking routes on maps, but this seems like a rather different activity to saying what the location of some text is. If you're making Cheapside as a path, thats an interpretative act, rather than a description of where the letters "Cheapside" can be found on the surface of the map. If the map does simply represent Cheapside as a zero-width (ifyswim) line, than you're trying trying to encode graphic features rather than text. In which case you need the full graphic language capabilities.
so put me down as a Reject but open to being argued against.
I take your point, but it's founded on the notion that we should only ever be interested in encoding text, and only interested in talking about the locations where text appears. That seems far too narrow to me. We already have encoding methods for figures, lines, and other graphical components of a text; I see no reason why we shouldn't be able to identify, link to and discuss paths on a facsimile surface as well as text.
This is one of those things where I'm actually actively doing this, because I need to, as part of a project that is a flagship TEI project for us. Should the TEI accommodate my needs, or push me away in the direction of tag-abuse (which is what I'm doing now), or adopting another standard (which would be SVG in this case, and mighty inconvenient)? This map is (as we hope to argue in Sidney next year) a text in multiple witnesses and versions, and we are trying to encode its textual history to some degree using the mechanisms TEI provides for this purpose.
On the other hand, of course, there is the obvious worry that as soon as you let me have paths and points, I'll be demanding curves and gradient fills and god knows what else and the TEI will go to hell in a handbasket.
<zone>s originally had only rectangles, but that was obviously inadequate, so @points was invented; perhaps this was the beginning of a slippery slope. But I would argue that what I'm asking for here is actually less complex than @points. A point or a path is a subset of a shape." ...we should only ever be interested in encoding text, and only interested in talking about the locations where text appears ...". Well, yes. That would seem to sum up the TEI :-}.
I am not sure I'd use SVG for this, I'd be looking at GIS-type markup. Not familiar enough with current standards to suggest what that should be, but why is it mightily inconvenient?
We only use GIS when a map is at least a semi-realistic representation of reality; this particular map is a combination of map, scenic view and idealization which cannot be practically geo-referenced. All the locations have GIS information for the "real world", but their location on this particular map is based on pixel offsets.
It would be inconvenient to use SVG because about half the locations are definable as shapes and can easily be encoded with
<zone>s; we have nice working code that goes from zone/@points to OpenLayers feature geometries. I started out by using SVG, and having to convert between SVG's path/@d attribute to OpenLayers geoms, but TEI<zone>s work for the shapes in a much more straightforward way, and it would be nice to be able to use a single pure-TEI representation for everything.I raised the ticket because it seems to me a straightforward and not unreasonable requirement; and because in any case we already have an ambiguity in the definition of @points, in that we don't say whether the final point has to be the same as the first in order to close the shape. If you choose to believe that not explicitly closing the shape gives you a path, then we already have (poor, underspecified and underdescribed) support for paths with more than two points. And, as I said, I think points and paths are less complex objects than shapes, so not supporting them is rather strange.
I certainly agree that the question about whether you need to repeat the 1st coord to close a shape is unclear, and needs a decision. I also agree in principle that "points and paths are less complex objects than shapes", but not at all that "not supporting them is rather strange"; because this whole notation was setup to describe where text occurs, and points and paths don't have enough dimensions to cover that.
Next thing we know, you'll be using <path> to encode the shape of letters, or the way marginal lines are drawn; and you'll want colour; and fill; and line thickness; and transparency; and uncle tom cobbley. All good stuff, but quite a different task.</path>
Assigning to Stefan. Look it over, discuss here and/or on the Council list, and get consensus on an approach/decide what to do with it.
Agreed about the ambiguity: a zone ought to be precisely defined as a closed polygon (there is an implicit continuation from the last point to the first one). We are less certain about whether or not to permit a distinct <path element. Use cases?