One comment regarding the @srsname attribute.

"The name of the spatial reference system used by the coordinates. The default is  "http://www.opengis.net/def/crs/EPSG/0/4326". If the attribute is not present the default is assumed."

This attribute was proposed to make the spatial reference system for IATI geographic data explicit and to conform to ISO-related metadata standards that are required by some governments for spatial data publication. However, I would strongly recommend that, for the time being, "http://www.opengis.net/def/crs/EPSG/0/4326" (WGS1984 decimal degrees) be not only the default but also the only permissible value for this attribute. 

Otherwise everything here seems in line with the discussions that have taken place over the last year.

Bill, your summary table says this:

The latitude and longitude coordinates in the format "lat lng"

Should they be comma or space separated?

(There's also a schema github issue at https://github.com/IATI/IATI-Schemas/issues/59)

GML, from which we're borrowing the markup, has them space separated, not comma separated:

http://en.wikipedia.org/wiki/Geography_Markup_Language#Point_Profile

Looking at the linked Wikipedia page, it looks like thes pos element has lat lng space separated, but the coordinates element actually has them separated by a comma and a space.

Additionally the coordinates element seems to be deprecated in GML 3.1 - should we be using the pos element instead?

It seems that the GML standard (and linked wikipedia pages) have been updated since we first wrote up the proposal. Before we get into it, a quick review of why GML was proposed:

• one government had brought up concerns about ISO-compliance in reporting geographic information. this was specifically remedied (per my limited understanding) by adding the spatial reference system explicitly, but also led to the decision to adopt GML markup wholesale for points
• starting with GML for points provides the scaffolding for implementing polygons and lines in future schema versions without having to invent increasingly complex markup ourselves
• GML is consumed natively by some mapping applications, which provides the potential for easier interoperability (although that point is somewhat limited since at a minimum you'd have to parse the IATI XML to extract the GML for coordinates)

It does bring in new complications though, as evidenced by this post. Specifically: (1) deciding which GML version to use and when to follow and upgrade, and (2) dealing with the somewhat weird markup decision of space separated coordinates for individual points but space separated sets of comma-separated points for other features (some of which can only contain one point and thus become comma separated).

At this point I am open to higher-level input about the trade-offs here, but from my side would not be opposed to keeping our custom point markup as long as we added the srsName attribute. (I would equally be unopposed to adopting GML, probably 3.x makes sense at this point.) For now a good interim solution might be to:

• keep coordinates
• deprecate coordinates/@precision
• add coordinates/@srsName
• table the discussion of the broader GML adoption for 2.0 to allow time for review of the GML versioning process and implications for IATI.

Thoughts?

Thanks for the exalpanation of why GML was proposed.

Currently, we're planning with the current proposal, of being compatible with a subset GML (specifically GML 3.3, but I think the subset we're using is the same in 3.0, 3.1 and 3.2).

However, we think that the should adopt the newer pos element, instead of the older and now deprecated coordinates element.