GeoWeb Standards – Where we need to go
In previous articles on the status of the GeoWeb I highlighted the myriad of options and problems with current GeoWeb standards and interfaces. Overall, it’s clear that the practice of geospatial data publication and sharing in a web oriented way is still very nascent but getting better at the same time it becomes more mainstream. More data is being created and published in web-oriented ways that make it more consumable and usable.
Too often standards and tools are being by domain experts and technologists that lead to overly complex, and irrelevant formats that become a burden and introduce as many problems as they are trying to solve.
What they’re often not considering are the end user experiences. Who are the users, what are they trying to achieve, and how can these formats make for better, and easier utilization of these tools.
Granted, there are expert users. People who really want to make intricately related, projected, spatially and spectrally bounded queries into data and utilize them in advanced analytics engines. But these are not the majority and they’re not what is driving the long-term demand on the GeoWeb (you can use ‘long-tail’ here if you would like). Who are the users that want to engage with this information on a daily basis in their personal lives, businesses, family, safety, governance, and goals.
Grassroots is an option
I’m a very big fan of grassroots organization and emergent structures. The needs tend to grow from real demand, and solutions are built through actual demonstrated benefit and impact. They are agile, evolutionary, and garner broad support amongst users and developers. These are all aspects that are beneficial to achieving standards that meet the needs of end users and provide good experiences.
However, it is not the only solution. Grassroots tends to look at the immediate needs and may not incorporate more distant issues and expected needs. They seek for broad appeal, and “good enough” rather than totally encompassing all potential aspects of all interested domains. Top-down, industry derived, committee driven standards provide more directed needs and objectives that can serve different types of users.
So the solution is a hybrid – where grassroots solutions are encouraged as demonstrators and emergent needs – that are then accepted and supported by more formal organizations.
Conversation is required
But we also need to open up the conversation beyond just technologists and experts. We need to be engaging and understanding users – and not merely from the “how do I sell them more of my coffee”, but “what can I do to make their lives better”? And actually asking and engaging with them in dialogues.
This technique of user stories, and engagement is not new or unused. However it appears to be missing from the GeoWeb standards developments. We’ve been designing standards for ourselves first, and then foisting these upon others. Instead, we need to understand their needs and issues, and then apply our expert knowledge in how to approach solutions properly.
Other articles in the GeoWeb Standards series:
My name is
August 28th, 2009 at 1:34 pm (#)
Hey Andrew,
It’s been a while since we’ve seen each other. Great series and terrific points you’ve raised. These are things I know I’ve been struggling with when mapping data online too.
It seems to me that there should be some sort of machine-readable *and* human-readable spec that would be the middle ground between any data source and existing data types (KML, RSS, CSV, GeoRSS, JSON, etc).
[Any data] -> [new human/machine spec] -> [Existing Formats]
This new spec should be generic enough to handle all kinds of data, from government SQL databases to spreadsheets, and specific enough to allow auto importing to the existing formats.
This new specification can be the one single format that sites like data.gov and city/state govs publish online. A casual user can use it since the fields are structured to be viewable in a spreadsheet. But developers can use it too to convert it into the formats they use for their sites.
I’ve come up with a proof of concept for this at http://www.omgstandard.com which tries to hit at these points. When I receive any data from online web sources or partnerships with local govs, I first convert it into this XOMGL format, which is how it’s stored in the database. Then when the site needs KML, it outputs as KML. When it needs CSV for a user to download, that’s what it can spit out. Same goes for RSS, JSON, HTML, and , all run through the API.
Of course it’s just a start, but it hits on the ideas of separating content into chunks (addresses, city names, latitude, longitude, name, html description [a catch all], date, categories, source metadata, etc) that can be repurposed. It really is just a way to define the granularity of fields, and what fields are required, without merging the data (like KML and RSS do) or splitting the data up (like GIS solutions do) too much.
Are some of these concepts what you are trying to grab and define?