Re: [OSGeo-Discuss] ESRI, please publicly share reasons for given for adopting the GeoServices REST API
Hi Cameron, I note you say disappointed rather than surprised. I agree, if the contents are not made public, or at least provided to all paying OGC members all voting OGC members, then I fail to see how the OGC can honestly claim the vote in any way reflects the preferences of its membership, rather than a vote by some members who were under some sort of pressure from a large multinational company. Brent Wood --- On Thu, 5/9/13, Cameron Shorter cameron.shor...@lisasoft.com wrote: From: Cameron Shorter cameron.shor...@lisasoft.com Subject: Re: [OSGeo-Discuss] ESRI, please publicly share reasons for given for adopting the GeoServices REST API To: Craig Sandy csa...@esriaustralia.com.au Cc: OSGeo Discussions discuss@lists.osgeo.org, tc-disc...@lists.opengeospatial.org, standa...@lists.osgeo.org Date: Thursday, May 9, 2013, 4:10 PM I have been notified that ESRI/OGC will not be sharing reasons for voting for the GeoServices REST API that has been sent to OGC voting members. I'm disappointed that such information is being with held from public debate. On 8/05/2013 4:51 PM, Cameron Shorter wrote: Craig, I understand that ESRI has been emailing some OGC voting members reasons for approving the GeoServices REST API. I think it appropriate to have an open discussion, and hear both the pros and cons for adopting the GeoServices REST API. Could you please share your comments on a public email list so that the community has an opportunity to hear the other side of the argument. -- Cameron Shorter Software and Data Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Data Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com -- -- The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] [OSGeo-Standards] ESRI, please publicly share reasons for given for adopting the GeoServices REST API
Hi Landon, OGC credibility is very much at stake here. Should we propose a name change? OGC - EGC? Little about this process seems genuinely open... and is getting less so as it drags on. Regards, Â Brent Wood --- On Thu, 5/9/13, Landon Blake sunburned.surve...@gmail.com wrote: From: Landon Blake sunburned.surve...@gmail.com Subject: Re: [OSGeo-Discuss] [OSGeo-Standards] ESRI, please publicly share reasons for given for adopting the GeoServices REST API To: Cameron Shorter cameron.shor...@lisasoft.com Cc: OSGeo Discussions discuss@lists.osgeo.org, tc-disc...@lists.opengeospatial.org, standa...@lists.osgeo.org, Craig Sandy csa...@esriaustralia.com.au Date: Thursday, May 9, 2013, 4:24 PM Does the OGC still have any credibility as a transparent standards organization after this? I'm very disappointed in ESRI and OGC based on what I've heard so far. Pretty hard to believe this is coming from the folks that first published the Shapefile specification that made a lot of open source GIS software practical. I guess that is what happens when there is a lot of short term profits on the line. How short-sighted. I hope they change their mind. Landon On Wed, May 8, 2013 at 9:10 PM, Cameron Shorter cameron.shor...@lisasoft.com wrote: I have been notified that ESRI/OGC will not be sharing reasons for voting for the GeoServices REST API that has been sent to OGC voting members. I'm disappointed that such information is being with held from public debate. On 8/05/2013 4:51 PM, Cameron Shorter wrote: Craig, I understand that ESRI has been emailing some OGC voting members reasons for approving the GeoServices REST API. I think it appropriate to have an open discussion, and hear both the pros and cons for adopting the GeoServices REST API. Could you please share your comments on a public email list so that the community has an opportunity to hear the other side of the argument. -- Cameron Shorter Software and Data Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Data Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com -- -- The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. ___ Standards mailing list standa...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/standards -Inline Attachment Follows- ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] ESRI, please publicly share reasons for given for adopting the GeoServices REST API
Feels like a huge attempt to undermine and side rail the OSS community. Maybe they are feeling a bit threatened. - Nathan On Thu, May 9, 2013 at 5:38 PM, pcr...@pcreso.com wrote: Hi Cameron, I note you say disappointed rather than surprised. I agree, if the contents are not made public, or at least provided to all paying OGC members all voting OGC members, then I fail to see how the OGC can honestly claim the vote in any way reflects the preferences of its membership, rather than a vote by some members who were under some sort of pressure from a large multinational company. Brent Wood --- On *Thu, 5/9/13, Cameron Shorter cameron.shor...@lisasoft.com*wrote: From: Cameron Shorter cameron.shor...@lisasoft.com Subject: Re: [OSGeo-Discuss] ESRI, please publicly share reasons for given for adopting the GeoServices REST API To: Craig Sandy csa...@esriaustralia.com.au Cc: OSGeo Discussions discuss@lists.osgeo.org, tc-disc...@lists.opengeospatial.org, standa...@lists.osgeo.org Date: Thursday, May 9, 2013, 4:10 PM I have been notified that ESRI/OGC will not be sharing reasons for voting for the GeoServices REST API that has been sent to OGC voting members. I'm disappointed that such information is being with held from public debate. On 8/05/2013 4:51 PM, Cameron Shorter wrote: Craig, I understand that ESRI has been emailing some OGC voting members reasons for approving the GeoServices REST API. I think it appropriate to have an open discussion, and hear both the pros and cons for adopting the GeoServices REST API. Could you please share your comments on a public email list so that the community has an opportunity to hear the other side of the argument. -- Cameron Shorter Software and Data Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Data Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com -- -- The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. ___ Discuss mailing list Discuss@lists.osgeo.org http://mc/compose?to=Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] inspire paper skeleton
Hi all, I did not receive any confirmation about our proposal [1] to INSPIRE conference yet, but never mind, I know, I should present more or less same paper to FOSS4G-CEE and other conferences this year and it would be good to start working on it. I have prepared basic skeleton of the presentation, at [2] and would like to ask anybody, who wants to contribute to the paper, especially project-insiders, to go on. I'll later convert the paper to LaTeX-beamer and share via github, so that anybody has access to the paper and can use it for her/his needs. You may also add other osgeo-related projects, which are e.g. still in incubation phase - I just copied the list from osgeo.org title page. I would like to add internal deadline to the wiki page - by end of May it should be done and conversion to LaTeX shall begin. Thanks Jachym [1] http://wiki.osgeo.org/wiki/INSPIRE_conference_2013#Paper_proposal -- Jachym Cepicky Help Service - Remote Sensing s.r.o. jachym.cepi...@gmail.com HS-RS: jac...@hsrs.cz http://bnhelp.cz http://les-ejk.cz signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] inspire paper skeleton
Hi Jachym, there is this nice tool [1] that allows to work together on a latex document. [1] https://www.writelatex.com On Thu, May 9, 2013 at 10:27 AM, Jachym Cepicky jachym.cepi...@gmail.comwrote: Hi all, I did not receive any confirmation about our proposal [1] to INSPIRE conference yet, but never mind, I know, I should present more or less same paper to FOSS4G-CEE and other conferences this year and it would be good to start working on it. I have prepared basic skeleton of the presentation, at [2] and would like to ask anybody, who wants to contribute to the paper, especially project-insiders, to go on. I'll later convert the paper to LaTeX-beamer and share via github, so that anybody has access to the paper and can use it for her/his needs. You may also add other osgeo-related projects, which are e.g. still in incubation phase - I just copied the list from osgeo.org title page. I would like to add internal deadline to the wiki page - by end of May it should be done and conversion to LaTeX shall begin. Thanks Jachym [1] http://wiki.osgeo.org/wiki/INSPIRE_conference_2013#Paper_proposal -- Jachym Cepicky Help Service - Remote Sensing s.r.o. jachym.cepi...@gmail.com HS-RS: jac...@hsrs.cz http://bnhelp.cz http://les-ejk.cz ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Best regards, Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] inspire paper skeleton
Yah, why not. But sill, I would prefer to start at the wiki - to collect the informations for the first step? Any opinion to this? Jachym Dne 9.5.2013 10:31, Margherita Di Leo napsal(a): Hi Jachym, there is this nice tool [1] that allows to work together on a latex document. [1] https://www.writelatex.com On Thu, May 9, 2013 at 10:27 AM, Jachym Cepicky jachym.cepi...@gmail.comwrote: Hi all, I did not receive any confirmation about our proposal [1] to INSPIRE conference yet, but never mind, I know, I should present more or less same paper to FOSS4G-CEE and other conferences this year and it would be good to start working on it. I have prepared basic skeleton of the presentation, at [2] and would like to ask anybody, who wants to contribute to the paper, especially project-insiders, to go on. I'll later convert the paper to LaTeX-beamer and share via github, so that anybody has access to the paper and can use it for her/his needs. You may also add other osgeo-related projects, which are e.g. still in incubation phase - I just copied the list from osgeo.org title page. I would like to add internal deadline to the wiki page - by end of May it should be done and conversion to LaTeX shall begin. Thanks Jachym [1] http://wiki.osgeo.org/wiki/INSPIRE_conference_2013#Paper_proposal -- Jachym Cepicky Help Service - Remote Sensing s.r.o. jachym.cepi...@gmail.com HS-RS: jac...@hsrs.cz http://bnhelp.cz http://les-ejk.cz ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Jachym Cepicky Help Service - Remote Sensing s.r.o. jachym.cepi...@gmail.com HS-RS: jac...@hsrs.cz http://bnhelp.cz http://les-ejk.cz signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Hey Cameron, all, Cameron, you recently asked me to join your letter from the OSGeo to the OGC Members regarding the adoption of the proposed ESRI GeoServices REST API as an OGC standard. http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_to_OGC_and_voting_members Thanks. Your request has forced me to define my position, which has been a huge waste of my time, but was probably worth doing. My response has two sides, my position on the debate and my decision to participate in the letter. The first is my position on the actual proposed standard. The pros: * The OGC should be in the business of developing good standards, not of choosing which standards should be implemented. * The proposers of the document want to make a standard and have followed all the rules of the consortium. The work of any such group of members deserves serious, good faith consideration. * The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue. * The proposed document could be useful to a number of people. * The proposed document is not significantly more broken than the existing standards of the OGC. As an author of standards at the OGC, I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable. The cons: - * The OGC is, de-facto, in the position of recommending the interoperable standards for geospatial services. The proposed document is not good enough, not widely enough implemented, and not publicly supported enough, to be considered at the same level as existing standards. * Adopting a standard implies a desire to maintain the standard but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version bodes ill for the future. * The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low. * There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implemetation. * The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services. * The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future. * The document needs a comprehensive editorial rewrite. (see at end) The problem for me, is that both simple answers are bad. A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a -new-name-here- solution instead of a W*S or a S*S solution. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. Fixing this document in addition to fixing the W*S services will be a pain. Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress. Is there a third way? Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through link following. That's the way forwards and why I have wasted a chunk of my life on WMS-Next. My personal conclusion, then, is that the vote does not concern me. I suspect the vote is mostly of interest to the commercial entities, groups whose self-interest is so destructive everywhere because it does not place user freedom and action first and foremost. Acceptance will have several net negative impacts on me but that's life, eh? For me, the path forwards is clear: make WMS-Next kick ass. The vote is merely a waste of my time. The second side to my response regards the actual letter. The pros: * The letter comes from the Free Software community which I think could have a voice on the matter. * The letter was started by someone who has my respect. * The letter re-enforces the link between OSGeo and the OGC. * The letter expresses many concerns which I share. The cons: * The letter
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 05/09/2013 07:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. Regards, Tim Bowden ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss it's not only rejection in the letter, there is also a way forward that I took the liberty to suggest: /The components making up the ESRI Geoservice REST API provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI Geoservice REST API, if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement. // / cheers, Peter -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (mail disclaimer, AD 1083) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Thanks Adrian for your email with your reasoned explanation. It's not often people take the time to provide such a thorough analysis. On May 9, 2013, at 1:56 PM, Adrian Custer acus...@gmail.com wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Having attended most of the first 50-ish OGC meetings and then a few here and there since, here's my perspective on the limits of governance. The problem is not so much the process (or wasn't, back in the day, it's become much more byzantine since then). The main problem is that most TC members either have no programming/architecture background or their expertise is fairly specialized. That means that for any given proposal, a small percentage of the members really understand it. Then, when it comes to a TC vote you have people voting based not strictly on technical grounds but also on business interests, political interests, even social interests. On top of that, I don't think that member companies are very knowledgeable about the policies and procedures and don't really know how to use their memberships to their best advantage. Taken together, this can lead to some fairly dysfunctional results. I believe that the Architecture Board (or whatever it's called now) was established in part to counter this effect. You'd have a bunch of knowledgable old hands benevolently watching over the output of the process who were going to make sure things hang together from a technical point of view. Perhaps the Architecture Board has been unable to provide sufficient guidance to the TC in this particular instance. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. In the end, everyone wins if specs are vendor neutral but also allow vendors to differentiate themselves by providing different qualities in their implementations. If a spec is passed that is simply a thin veneer on top of an existing vendor's implementation, then that vendor has a head start over others. If the OGC members are collectively unwilling or unable to push back against this, then this kind of thing is the result. It's really a Darwinian microcosm within a mutually agreed upon set of rules. If the results are irrelevant, confusing, or outrageous, then over time the organization will suffer and become less relevant. Allan Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Adrian, Thanks for the in depth review. I admit I haven't read the document over thoroughly but even without doing so there are some obvious concerns. From a user perspective (my user), this appears to be a push to get their way of doing things stamped as a standard so they can let their users (e.g. government agencies) claim compliance with Open Standards without having to use WxS. I can see this first hand with my own personal experience trying to get WFS/GML to work with Arc (supposedly supported with special add ons) and government agencies thinking if they put up an Arc Service they've done their duty: https://services.gis.ca.gov/arcgis/rest/services/Government/CPAD_19/MapServer (Note the confusing url that implies MapServer software, and the lack of any non ESRI web service on the page) To me it looks like they are trying to get out of spending the money to fix their products so they place nice with all the existing services. I agree though, that simply turning ESRI away isn't a solution either, at least they came to the same standards body unlike the OASIS/ISO debacle over Office formats. Is there someone in the OGC community that could reach out and negotiate a plan to merge their work and ideas with the existing standards instead of creating a direct competition to what is already widely adopted. If they really want it to be a standard they have to be willing to compromise on some feature to make it more interoperable, in a sense kml did this by not including all the possibilities in the original spec. I also agree 50+1 is a bad bar for a standards body. Which reminds me that I dropped the ball on renewing my institution’s membership (though I don't think it had voting rights). Thanks, Alex On 05/09/2013 10:56 AM, Adrian Custer wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Adrian, This is an exceptionally well written letter, which I believes captures what many of us in the OSGeo Community would like to say. You have provided an eloquent, unbiased, concise summary of the issues, covering the key technical issues. If an OGC voter only had time to read one thing before voting, I would recommend they read this email of yours. As such, I'd like to work with you to see what the best way would be to incorporate your text into our open letter at: http://wiki.osgeo.org/wiki/Geoservices_REST_API (assuming that would be ok with you). I'd like your text in this open letter, as I'm expecting it to have lots of OGC Voters reading it. I note that we already have a number of people have collated reasons for not voting for this standard. I suggest that we invite these authors to check if their concerns have been covered by your summary, and if so, remove their duplicate concerns. Anything left can either be added by Adrian Custer into his summary, or collected in a Further Comments section at the end. Adrian, What are your thoughts? On 10/05/2013 2:20 AM, Adrian Custer wrote: Hey Cameron, all, Cameron, you recently asked me to join your letter from the OSGeo to the OGC Members regarding the adoption of the proposed ESRI GeoServices REST API as an OGC standard. http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_to_OGC_and_voting_members Thanks. Your request has forced me to define my position, which has been a huge waste of my time, but was probably worth doing. My response has two sides, my position on the debate and my decision to participate in the letter. The first is my position on the actual proposed standard. The pros: * The OGC should be in the business of developing good standards, not of choosing which standards should be implemented. * The proposers of the document want to make a standard and have followed all the rules of the consortium. The work of any such group of members deserves serious, good faith consideration. * The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue. * The proposed document could be useful to a number of people. * The proposed document is not significantly more broken than the existing standards of the OGC. As an author of standards at the OGC, I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable. The cons: - * The OGC is, de-facto, in the position of recommending the interoperable standards for geospatial services. The proposed document is not good enough, not widely enough implemented, and not publicly supported enough, to be considered at the same level as existing standards. * Adopting a standard implies a desire to maintain the standard but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version bodes ill for the future. * The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low. * There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implemetation. * The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services. * The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future. * The document needs a comprehensive editorial rewrite. (see at end) The problem for me, is that both simple answers are bad. A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a -new-name-here- solution instead of a W*S or a S*S solution. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. Fixing this document in addition to fixing the W*S services will be a pain. Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress. Is there a third way? Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to
