... personal wiki, blog and notes
Having our granule cake and eating it too
Over on import cartography, Sean is convinced he's not sabotaging the fight for a sustainable climate. He's right.
His post was inspired by a sequence of emails (most of which I haven't read), which culminated in this one.
I must say I'm depressed with how often folk manage to get themselves in one of two states: my hammer is suitable for all problems (including screws), or if you dis my hammer I will never be able to strike another nail.
To be fair, I sometimes find myself in these camps too (I told you it was depressing!)
Anyway, the thread Sean highlghted is particularly frustrating, because I don't think the two camps need to be far away. There is a place for clean, easy to use mashable technologies, and, complex, powerful, complete descriptions of geospatial objects. And guess what? Sometimes that place can coincide!
Just today I mentioned that we were moving MOLES towards using ATOM as a container technology. So, not yet fully thought out, but just to make that point, here is something approximating UML for a new MOLES granule:
The point to note is that the inoffensive little object in the bottom left corner includes a GML feature collection in CSML, using the entire crufty(but useful)ness of GML, and it's pointed to as atom content.
We do intend to have our cake and eat it too! We should be able to both mash up and consume our complex binary objects. I don't see why we can't see complex GML descriptions as cargo of georss flavoured atom, just the same as a photo might be!
For the record, some things to note in this are
We need to flesh out a when object, because the atom time stamps are about the atom record, not the time of the enclosed data objects.
We need a logo element attribute of the dgEntity because an Atom entry doesn't have a logo (even though a feed does).
We have some specific elements to ensure we could produce an ISO record with mandatory components.
We have made the decision that the atom author and contributor should refer to the author and contributors of the enclosed CSML content, not the metadata writer (who produces the summary text, who appears as the metadata maintainer).
Of course now we might be able to build services which are easier to exploit than the OWS stack though ... (but meanwhile we are building one of the them anyway).