Some notes and questions on the 1.04 schema changes about iati-schemas

[Bjwebb]

I think that using point instead of Point could be a problem, since I think it's meant to be consistent with some other standard.

[Bjwebb]

Deprecation has been split out into a sepreate issue - #58

[caprenter]

Have asked Owen about the Point point

[owenscott]

See related discussion here: http://support.iatistandard.org/entries/30339187-New-Location-Point-element

Our idea was to adopt consistent markup with GML. Two reasons: (1) consistency with other standards. (2) implicitly putting in place the scaffolding for adopting standard markup for line and polygon features if we ever go that way in the future.

At the same time, point vs Point violates the uniformity of the IATI standard by having a capital letter. I could be swayed either way, but having gone partway down the line of using GML, it might make sense to go all the way...

[bill-anderson]

On our last call we agreed to go with point

[Bjwebb]

We've discussed this further, and I think that Point would be better from a compatibility point of view.

XML is case sensitive, so the distinction between point and Point does matter if we want people to be able to take the XML element, and feed it directly into something that understands GML. We've decided to use the same markup as GML, going as far as to add a srsName attribute that only ever has one value.

This being the case, I think it would be helpful to people creating/consuming IATI data if we went all the way, and used exactly the same tag names as GML, and adopted Point.

[caprenter]

We also discussed the option of including the GML elements as a namespace.

It seems to me that using the gml: namespace is an option here. (Just as it is used in the wikipedia example Owen references in the forum post (http://support.iatistandard.org/entries/30339187-New-Location-Point-element) about this: http://en.wikipedia.org/wiki/Geography_Markup_Language#Point_Profile).

But I also understand that this idea had been rejected previously (if anyone can point to words on that, I'd appreciate it) so this may be irrelevant.

We would back it up with documentation (in the same way we do already. We can for example specify a version of GML to use with each version of the standard).

I think this make us slightly more future proof. It allows better alignment with GML (as it is GML). And it allows us to experiment and see how data publishers use it and get on with it.
Thinking about what might be different in 2.01 (3.01) might help.

Opinions welcome!

[owenscott]

My vote would be against using the gml: namespace explicitly based on two things. (1) @davidmegginson recommended in favour of markup emulation without namespacing, and i tend to take his word over my own on XML stuff. (2) We've already seen some confusion, in this forum post (http://support.iatistandard.org/entries/30339187-New-Location-Point-element) about changes to the gml syntax that aren't being tracked in IATI, so this is probably a good way to avoid that...

But i could be swayed if there is a way to do namespacing which is explicitly versioned to a particular version of GML, which I'm sure there is?

[owenscott]

Also, @Bjwebb , just to share an opinion on srsName, I think that's actually the most meaningful thing we've done here. Even though it only ever has one value, it eliminates a tonne of ambiguity.

In 2010 in Malawi I spent time working with a consultant doing a comparitve evaluation of two rural water supply mapping exercises which took place 5 years apart. Both used projected coordinate systems using Eastings and Northings. However, the first one used the ARC1950 datum (http://georepository.com/datum_6209/Arc-1950.html) while the second used the more standard WGS1984 datum. Both used project easting/northing coordinates which were basically identical when looked at as strings except for small changes in values.

The result was that, because of the different datums used (btw a datum is a mathematical 3d simplification of the world onto which coordinates are projected) all of the points were off from each other by about 100 meters, leading the consultant to write a fairly scathing report rejecting the accuracy of the original map. In reality, both maps were accurate, their coordinate data just used different datums, which weren't recorded in metadata. Lots of time lost and feelings hurt over something simple.

Including our geographic metadata explicitly prevents us from causing this problem for someone else. Restricting it to one value prevents people from getting crazy with datums and causing headaches for IATI users. I think it's a good compromise.

:)

[Bjwebb]

@owenscott I definitely agree that explicitly defining the spatial reference system is an important thing to do. My thinking was that if we were not using (a subset) GML, it could just as easily be defined in the text of the standard, rather than in the data files. However, I can understand that in practice people using the data will be looking at the data more closely than they are at the text of the standard.

[bill-anderson]

My (non-xml) take is

• Namespace is not a good idea for a piece of data that is fundamental to our own standard
• "Point" rather than "point" will create errors and confusion among the majority non-cognoscenti
• We should say that our version is derived from (rather than based on, or compatible to) gml

[davidmegginson]

@owenscott wrote "@davidmegginson recommended in favour of markup emulation without namespacing"

I don't remember that recommendation, but then again, I don't remember a lot of the things I say. Our general approach with IATI has been to use namespaces for extensions only, though, so I do think that what @owenscott and @bill-anderson said about not using a namespace makes sense.

As for "Point" vs "point", our general style in IATI has been LISP-style lower-case, hyphenated names, such as foo-bar instead of FooBar or foo_bar — if we can stay consistent and use "point", that's a good thing. I'm not a GIS specialist, though (just an enthusiastic amateur), so I can't speak to any specific difficulties that the case difference might case.

[bill-anderson]

So you want the rank outsider amateur to make the call ...

Lower case