Hi Josh,
Interfaces, models, and encodings are all different animals. JSON might
be a very useful encoding for certain applications of certain
list-of-list information models (which comprises most extant feature
types). It doesn't yet carry the schema and hierarchy tools of XML, nor
the feature model of GML.
Since JDIL implements the RDF data model (a URI-labeled object-property
graph), the RDF tools for defining schemas/classes (RDFS and OWL) are
directly applicable. Building up feature and geometry capabilities on the
RDF side is a possibility, possibly porting GML constructs (which would be
eased by GML's RDF roots).
But as Anselm and Allan have said, more immediate practical needs are
driving "guerilla spec development" - needs such as a mechanism for
transporting graphs (not just trees) representing basic geography. JDIL +
GeoRSS gets this far.
However, there is an issue with GeoRSS for carrying geometry: it encodes
sequences of coordinates inside strings (as does GML). This requires
parsing and conversion before the data can be used in geometric algorithms.
It is more efficient to send geometry encoded using the natural data
structures (points as objects with latitude and longitude as numerical
fields; coordinate sequences as arrays of numbers or points). It would be
simple to formulate a variant of GeoRSS that fixed this problem - perhaps
adding a JSON variant to the existing (or at least staked-out) simple,gml,
and micro. An idea, anyway.
-- Chris
----- Original Message -----
From: "Joshua Lieberman" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 07, 2007 8:31 AM
Subject: Re: [Geowanking] JSON for GEO
Chris, thanks for looking at the baby "and" the bathwater.
Interfaces, models, and encodings are all different animals. JSON might
be a very useful encoding for certain applications of certain
list-of-list information models (which comprises most extant feature
types). It doesn't yet carry the schema and hierarchy tools of XML, nor
the feature model of GML. WFS as an interface is commonly used to serve
other encodings than GML. Currently the spec says "GML" plus whatever. A
profile could make that more useful for JSON-based communication. I'm
still a little wary of new stovepipes being created, though, whether they
are open-source stovepipes or not.
I hope that instead of turning into some sort of an either/or battle, it
can be the impetus for useful alternatives: simpler encodings, simpler
service profiles, perhaps even a division of GML into the ISO- based
feaure model (quite general), and the XML encoding (more specialized).
As Allan notes, getting to a useful proposal in finite time for OGC to
consider often takes outside action, as in GeoRSS. GeoRSS is based on OGC
specifications, though, not set in opposition to them.
Cheers,
Josh Lieberman
On Feb 7, 2007, at 11:10 AM, Chris Holmes wrote:
To echo Allan, I don't see this work as moving away from OGC standards.
On the contrary, I view it as helping the OGC, by leveraging and
adapting their interfaces for more uses. I intend to serve GeoJSON
through WFS, and indeed when we added network link KML support to
GeoServer we did so through WMS. And we continue to add more standard
support, with certified WFS 1.1 and WCS 1.0 coming out soon. But that
does not mean we wait for OGC approval on everything we do.
And I do hope the work that we do will feedback in to OGC standards,
drawing inspiration from GeoRSS, which started ad-hoc and is now
endorsed by the OGC. I'm used to working in an open source manner,
communicating over email and IRC, and I simply can't afford to attend
quarterly OGC meetings all over the globe to talk about things. So I
hope by working in the best way I know how I can contribute to their
standards process.
And I agree with Allan that some OGC specs are not that usable, and I'm
working to make them so. I still feel WFS is a good spec, but it's
weighed down by the fact people think it's tied to GML. So making
GeoJSON output for it seems ideal to me. I think WFS-T is a very solid
API, but it doesn't include any versioning, so we're working on that
(http://docs.codehaus.org/display/GEOS/Versioning +WFS). And yes, I hope
to feed our work back in to WFS in a future revision, but until that
point the best way for us to work is to collaborate with everyone. Then
when it comes in to the OGC it's something working in the world and
tested under real conditions, instead of a group of architects getting
together to design a blueprint for a cathedral that might fall apart or
just be too hard to build when it's finally released to the world.
best regards,
Chris
Allan Doyle wrote:
On Feb 6, 2007, at 19:26, [EMAIL PROTECTED] wrote:
Hello,
I've been following the discussions on JSON etc for GEO.
IMO:
I'm finding that Open Source spatial projects are getting increasing
attention from large organisations.
This is largely due to a strong support for OGC standards in key OS
projects and an organisation's desire for vendor neutrality.
While I can sympathise with performance concerns, I'd recommend that
projects do not move away from support for OGC Standards.
There has been a great deal of thought and effort into getting the
standards where they are today. If specific OGC standards are not
working or have problems, we as an industry need to work with OGC to
make sure that the issues are resolved.
Open Source geo projects were among the first to implement and OGC
specs and then those implementations have become widely used, thus
helping to bring about further acceptance of OGC specs.
I think it's in fact the case that those specs that have found their
way into widely used open source implementations are those specs that
are considered to be working or at least workable by the broader
community. If you want to know which OGC specs are not working, then to
first order look for those that are not implemented in open source.
Many individual OGC members have a pretty good idea of which of their
specs are usable and which are not. Furthermore, they also have a
pretty good idea of what kinds of specs the broader community needs.
The trouble is that OGC is a large organization with many different
constituents and a process that is, dare I say it? - rather ponderous.
There's no way someone on this list, working for a small, fast-moving,
mindshare and buzz-seeking startup can afford to wait for 18 months for
OGC to come up with a JSON Geo encoding. Particularly when there's no
guarantee that the spec would ever see the light of day.
There have been some rumblings coming from inside OGC recognizing this
and recognizing the need to adapt. I think it's a case of the
barbarians having to be at the gate before you can persuade anyone to
start boiling the oil.
Perhaps rather than try to fit geowanking with what is probably as
opposite to OGC as you can get, it might be the fact that guerilla spec
development is just the shot in the arm OGC needs to get enough
internal momentum going for a change.
Allan
Bruce
---------------------------------------
Bruce Bannerman
IT Solutions Architect - GIS
Department of Primary Industries - Victoria
Australia
Bruce dot Bannerman at dpi dot vic dot gov dot au
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
--Allan Doyle
+1.781.433.2695
[EMAIL PROTECTED]
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
!DSPAM:1003,45c93423191287785049143!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
<cholmes.vcf>
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
