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
