[OSGeo-Standards] [RESTful-Policy.SWG] [OAB] Encodings and REST

Sun Oct 21 09:22:29 PDT 2012

Pat,

I agree with you, that they way ESRI is doing it it the way it works.
But it's just not the way I'd like it to be.

Call me a whiner, a dreamer, naive or whatever. I believe in open
source, open development and open discussions. Creating the next cool
RESTful guidelines for the geospatial world should be open to anyone.

I'm well aware, that there might not be more contributions when the
RESTful Policy SWG work would be on a public mailing list, but at least
there would be a *chance* to.

The way the whole GeoServices REST API thing turns out makes me wonder
if the OGC is what I'm after. I like the idea of the OGC, but not how it
works in reality. Aren't there any alternatives? Why should the next
RESTful geo APIs be developed within the OGC? Is there a good reason?

In the end you can even try to get the specification you've worked on
through the OGC via the fast-track process. Just act as other vendors
and push your thing through.

Cheers,
  Volker

On 10/21/2012 02:47 PM, Pat Cappelaere wrote:
> Volker,
> 
> I am sorry to tell you that your comments sound like whining.
> ESRI and a few others are putting the money, time and effort into this standard.  This is the way it works.
> 
> There is nothing that precludes others to come up with something better, cheaper and simpler.
> The bad part of this community is that there is a long list of by-standers, unwilling to make a similar effort but to criticize.
> [I am not targeting you specifically as you are one of the few active members of the SWG]
> 
> Trying to develop a standard outside of the OGC is not easier.
> 
> As far as GeoServices using the REST moniker, this does not bother me as much anymore.  They are barely at level 1.5.  We already can envision what a level 4 might be in order to get to the summit at level 5.  So, as you know, I have already moved on as their standard is already obsolete in my mind.
> 
> Yes we can define a better JSON that will support these higher levels.
> We can define simpler bindings across OGC services that would enable newcomers and a wider community.
> However, this takes money, time and energy.  Barking at ESRI does not do us any good.
> 
> I do care about this.  I am putting my money, time and energy into this.  [I am certainly not saying that I am right but I am continuing the journey]
> 
> You all can make a substantial difference by working together at it.
> 
> Pat.
> 
> 
> On Oct 21, 2012, at 5:31 AM, Volker Mische <volker.mische at gmail.com> wrote:
> 
>> Hi Pat,
>>
>> On 10/20/2012 11:29 PM, Pat Cappelaere wrote:
>>> Do you guys really think that GeoJSON is the solution anyway?
>>> I don't think so…
>>
>> It's a good point. But yes I think so. About a year ago Sean Gillies
>> asked, if there should be a new revision of the GeoJSON spec to
>> incorporate recent developments. If ESRI is missing something, this
>> would have been a way to get it in. Though it could definitely be the
>> case that ESRI wasn't aware that Sean was asking for changes/new additions.
>>
>>> Now, if you were to turn GeoJSON into a profile of JSON-Schema to replace Geo… see http://json-schema.org/
>>> and if we were to add a little more to beefup hypermedia support and action links/activities… then this would more likely meet our needs.  But this is work!
>>
>> I would use GeoJSON as the encoding of a geometry. Hypermedia support
>> can be a separate format that embeds GeoJSON.
>>
>>> They have something that work for them… why would they change their standard?  just to please you guys?
>>> They have put a lot of effort and energy into this. I say: Good for them.
>>
>> I'd like to  put my cards on the table, I've a pretty negative view on
>> ESRI. I not exactly where it comes from, but it's that way. Hence I
>> probably see mostly the negative sides. My view is, that ESRI isn't
>> interested in having a common format, they want theirs no matter what.
>>
>> The support for GeoJSON in existing software is way bigger than it is
>> for theirs, why using theirs then?
>>
>> Originally the GeoServices REST API was proposed to go through the OGC
>> fast track process, which is meant (again that's my personal view) for
>> well established standards, to make the OGC standards (side node:
>> GeoJSON would be a candidate for it). Luckily a SWG was formed instead.
>> But the limitation that it needs to be backwards compatible is just a
>> too huge burden. One vendor wants to make his implementation a standard.
>> I don't think this is how things should be.
>>
>>> Arnulf and Volcker!  Time has come for you guys to decide if you want to work on this or let it happen.
>>> Complaining about it does no good.  Sorry!
>>
>> You are absolutely right. And I really think about the consequences. I'm
>> thinking about to stop being a member of the OGC and try to convince the
>> company I work for to pay this money instead to the OSGeo. And then try
>> to establish a better environment for making nice, valuable, working
>> standards. I know that's a huge goal and I might not even get close to
>> it. But the way the OGC works is just not how I think things should be.
>> I believed a long time that things aren't as bad in the OGC as people
>> are saying, but now I come to the point where I agree with those (side
>> note: a good read about problems of standard/standard bodies [1]).
>>
>> I don't know the story how the GeoJSON specification came into existence
>> (as I wasn't part of the FOSS4G community back then), but it seems to
>> have worked very well. I'd like to see more of that.
>>
>> Pat, I really enjoy having you as a chair of the RESTful Policy SWG. I
>> think you break many OGC rules as you wanted it to be as open as
>> possible. And I think that's really really good. But what do we need the
>> OGC for, if it could also be done completely in the open. Now that one
>> of my goals, not having the word "REST" in the GeoServices REST API
>> failed (and yes, I blame myself too, the policy might already exist, if
>> I would have put more effort into it).
>>
>> This is what I meant with "time to move on" in my tweet.
>>
>>> What do you all want to do?
>>
>> What I really wanted is an organisation that cares about making a
>> better, not one where vendors push for more money.
>>
>> [1] http://www.mikealrogers.com/posts/the-specification-paradox.html
>>
>> Cheers,
>>  Volker
>>
>>
>>>
>>> Pat.
>>>
>>>
>>> On Oct 20, 2012, at 11:40 AM, "Panagiotis (Peter) A. Vretanos" <pvretano at cubewerx.com> wrote:
>>>
>>>> Arnulf,
>>>>
>>>> I think the reasoning was that the JSON representation in the proposed Geoservices standard pre-dates GeoJSON and there is already an install base using that encoding.
>>>>
>>>> I think this issue, however, extends beyond encodings to API's as well.  I still have a hard time seeing why OGC needs 2 catalogue APIs, 2 web mapping APIs, 2 feature access APIs, etc ...  I think this will confuse the market.
>>>>
>>>> Ciao.
>>>>
>>>> On 10/20/2012 08:54 AM, Arnulf Christl wrote:
>>> Folks,
>>> I neither followed the discussion closely not the decision process of
>>> the SWG. Can somebody summarize the rationale of the Geoservices REST
>>> API group for not implementing GeoJSON but going down another route?
>>>
>>> Somehow it seems like OGC is becoming just yet another party in the
>>> general noise of format proliferation. We did better in other areas,
>>> how come we cannot stay on top of this one?
>>>
>>> This is pretty clear language, how are we going to address it?
>>> https://twitter.com/vmx/status/259275792817741824
>>>
>>> Apparently this comment by Volker Mische (who we know as supportive to
>>> the OGC) is receiving a lot of positive support in the broader
>>> geospatial IT crowd. Ignoring is not a solution.
>>>
>>> Cheers,
>>> Arnulf
>>>
>>> On 10/20/2012 12:46 PM, Peter Schut wrote:
>>>>>>> The good thing about standards is that there are so many of them.
>>>>>>> The bad thing about standards....
>>>>>>>
>>>>>>> Cheers, Peter.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 19, 2012 at 11:49 AM, Jeff Harrison
>>>>>>> <jharrison at thecarbonproject.com
>>>>>>> <mailto:jharrison at thecarbonproject.com>> wrote:
>>>>>>>
>>>>>>> It's my understanding that the GeoServices REST group has rejected
>>>>>>> integrating GeoJSON.  I suppose this means that if OGC passes
>>>>>>> GeoServices REST with its current JSON, there will then be 'OGC
>>>>>>> GeoServices JSON'. Which means this could be added to OGC GML,
>>>>>>> GMLsf and OGC KML on the list of encodings vendors may need to
>>>>>>> support. Then there could be OGC GeoJSON if that angle moves
>>>>>>> forward.  Add to this the fact that there will likely be an OSM
>>>>>>> JSON API next year, as well potentially an OGC GeoPackage.
>>>>>>>
>>>>>>> So the 2013 interoperability tech landscape, for geospatial
>>>>>>> features alone, could look like -> OGC GML, OGC GMLsf and OGC KML
>>>>>>> ... GeoServices JSON, GeoJSON, OSM JSON, ... GeoPackage
>>>>>>>
>>>>>>> Is it just me, or is this a really long list?
>>>>>>>
>>>>>>> Regards, Jeff
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>>>> _______________________________________________
>>>>> OAB mailing list
>>>>> OAB at lists.opengeospatial.org
>>>>> https://lists.opengeospatial.org/mailman/listinfo/oab
>>>>>
>>>>
>>>> -- 
>>>> Panagiotis (Peter) A. Vretanos          CubeWerx Inc.
>>>> Big Kahuna (Senior Database Developer)  http://www.cubewerx.com
>>>> Tel. 416-701-1985  Fax. 416-701-9870    pvretano at cubewerx.com
>>>>
>>>> To the optimist, the glass is half full; to the pessimist, half empty.
>>>> To the engineer, the glass is twice as big as it needs to be
>>>
>>
> 