[OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Personal opinion in a nutshell: From an OGC perspective: (yes I'm a member via NIWA's affiliation - once I pay the current bill :-) This is not a genuine attempt to improve interoperability support open standards, it is an attempt to undermine open standards replace existing open standards which are widely used supported in the community by ratifying standards currently used by one commercial vendor. I'm currently responsible for implementing federated (interoperable) systems between research agencies central/regional govt based on OGC standards. It these standards provide for disparate ways of doing the same thing, then OGC standards compliant: will mean one of two things: - may or may not work together depending on which OGC standards are supported - everyone has to support both standards to be fully OGC compliant. My organisation has just been quoted a few 10's of thousands of $ to develop a CSW service for ESRI datstores because, despite their claimed support for these standards - it is pretty minimal of limited functionality use. At present we can build federated, interoperable systems including CSW, SOS, WMS, WCS, WFS, etc, and if an agency fails to interoperate, that is their problem. This change would fundamentally reduce, if not destroy, the value of OGC standards to the wider community. From an OSGEO perspective (I'm in the Australia/NZ chapter) This weakens the FOSS community strengthens ESRI's place in the global GIS community. OSGEO is there (IMHO) to support FOSS GIS. Agreeing to a change which gives a commercial competitor a strategic advantage - giving them a mandate to let the FOSS community play catchup - is NOT in the best interests of the FOSS community. From a FOSS perspective (I'm a council member of the NZOSS), This is pretty much a repeat of Microsoft's refusal to support an existing, community based XML document/file standard their forcing of a competing standard on the community, which has been of no value to the user community created problems for the FOSS community. We should learn from that fiasco not make the same mistake again, as much as it in our power to prevent it. Regards, Brent Wood___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
I think we must review how openoffice become iso standared, and microsoft that behave like esri, want new standard called msoffoce xml. He submit his docx, xlsx, etc, which he said better and more complete, but anyone adopt. For respect, i hope we can follow this model. Esri no need standard, or using his api as new standard, that is bad. Happen in java world, people in community use struts as standard in 1999, competitor come, smiliar case, a standard body inside sun organization called jcp, play with new standard called jsf. Boom. Oracle and sun make standard from new standard, and reject struts or action framework or an adoption from html request response, this case happen several time by them, jdo, ejb. That bad for ecosystem, none use esp they, and marketshare still low until today. My proposal if the current standard can be extend, that is better, with esri's new standard rather create one, esp this is a ms office in gis world, dangerous for ecosystem, this is about marketshare and business in their side. I prefer they submit to iso or oasis. F On May 5, 2013 4:21 AM, Cameron Shorter cameron.shor...@gmail.com wrote: Adrian, Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help. I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening. On 05/05/13 02:43, Adrian Custer wrote: Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/**standards/requests/89http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hello, I've made a brief summary of this thread and sent it to the Spanish Local Chapter mailing list linking specially the mail from Cameron[1] that started the conversation. I've tried to encourage them to participate in the debate, right now we are receiving some responses, in spanish in the spanish list, I'm going to wait a couple of days and translate them to english and copy them in Discuss. I think that all the Liaison Officers from the Chapters should do the same and try to make their communities aware of this situation. Bests, [1] http://lists.osgeo.org/pipermail/discuss/2013-May/011599.html On Mon, May 6, 2013 at 11:34 PM, Adrian Custer acus...@gmail.com wrote: Hey Ann, all, On 5/6/13 5:48 PM, Anne Ghisla wrote: Stephan, Adrian: is there an effective way for OSGeo to address a statement to OGC, beside the official requests for comments and our Discuss list? Thanks for your thoughts, Anne Any official statement issued by the OSGeo Board or community on this particular vote should probably be addressed to the 'Voting Members of the OGC Technical Committee' since they are the ones who are taking a position during this vote and deciding whether to accept it or not as an official OGC standard. The statement could be sent via Carl Reed, who is the head of the OGC Technical Committee. He lurks on this list as part of the collaboration agreement between the two communities and can be reached directly at: creed U+0040 opengeospatial.org ciao, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Pedro-Juan Ferrer Matoses Valencia (España) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On 7 May 2013 08:58, Pedro-Juan Ferrer Matoses pfer...@osgeo.org wrote: Hello, I've made a brief summary of this thread and sent it to the Spanish Local Chapter mailing list linking specially the mail from Cameron[1] that started the conversation. I've tried to encourage them to participate in the debate, right now we are receiving some responses, in spanish in the spanish list, I'm going to wait a couple of days and translate them to english and copy them in Discuss. I think that all the Liaison Officers from the Chapters should do the same and try to make their communities aware of this situation. Bests, HI I won't repeat the arguments, but I fully agree Adrian, Bruce, Andrea, Daniel etc on how bad for the geospatial community would be to have such a broad standard overlaping existing WxS services. We need to improve WxS services and help OGC to evolve them to current market needs, not throw to the bin years of knowledge and community driven efforts. Cheers -- Jorge Sanz http://es.osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for both it and traditional W*S services? Bruce ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Adrian sums up the problems and the discussions that were happening really well. I fully agree with the problems that arise. I just want to add that from my perspective this isn't an anti-ESRI campaign from some OSGeo fellows, but it's against one company pushing something through the OGC that defeats a lot of the efforts from the people that want to have open standards for the greater good. I appreciate that ESRI publishes their specification of the product, so that others don't need reverse engineer it in case you want to have interoperability. Though it would make much more sense to me to have it published on their website and not having it pushed through the OGC to have some approval from a standardisations organisation. It really describes their product and it's not about harmonisation/interoperability. Cheers, Volker On 05/04/2013 06:43 PM, Adrian Custer wrote: Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design). The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. The name of the standard
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
I am also of the opinion that single-vendor standards such as KML and this GeoServices REST API are turning OGC into a rubber-stamping organization and this is not what the geospatial community needs. Don't get me wrong, it is good to see these openly published, but the publication should be by their owners (Google and ESRI in those case) and not be rubber-stamped by OGC. What the geospatial community needs is an organization that provides direction around a consistent set of standards that guarantee interoperability between interchangeable software components. The suite of WxS services built over the last 10-15 years is somewhat on the way of achieving this, even if some pieces still do not interoperate as smoothly as we wish. Is OGC trying to tell the world that it no longer believes in WxS? OGC and its members need to decide whether they want the OGC logo to be perceived as the guarantee of interoperability, or just as a rubber-stamping organization with a large portfolio of inconsistent standards. Whether your source is open or closed is out of the question here, so I am not sure that a statement from OSGeo matters unless it is to point at this obvious slippery slope in which OGC is falling (a movement which started with KML a few years ago). Daniel On 13-05-06 3:41 AM, Jeroen Ticheler wrote: All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for both it and traditional W*S services? Bruce ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
All, I'm pretty much in the same camp as Jeroen has described below. The original advertised capabilities from OGC were to develop a set of common and documented standards that could be used as interoperable building blocks. It was supposed to be a nice and easy way to say that I, (or we) as developer(s) is/are adhering to a standards approach. It was supposed to be easy to rally around. As noted elsewhere in this thread the KML stuff seemed to fracture the OGC universe somewhat. I had a hard time with its introduction as a standard at the time as well. Each of these new introductions of processes seem to fracture the original OGC intents even further as far as being a set of standards to point at. Now even after having said all of this, how does the community maintain a standards approach while still embracing change. New approaches need to be vetted and possibly approved as to what they are are and what their capabilities are. The bigger piece here seems to be the missing aspects of description needed by the end users of the standards, and about what those standards are really capable of, and second, and probably more important, how popular it is to the Open community. I have no idea how a popularity ranking might occur, but it would allow for all sorts of approaches with various standards being introduced but also demonstrate which ones are being used the most. Hmmm, maybe OGC needs an Incubation stage of adoption, which lets a following build (if it's there) or not. Bobb -Original Message- From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Jeroen Ticheler Sent: Monday, May 06, 2013 2:42 AM To: bruce.bannerman.osgeo Cc: discuss@lists.osgeo.org Subject: Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard? All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for both it and traditional W*S services? Bruce ___ 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] Would you be concerned if the GeoServices REST API became an OGC standard?
The part that bothers me the most about this has to do with the big picture. I'm concerned that if we focus on this or that standard without putting it into the larger context that poor(bad?) decisions are getting made that set precedents for more bad decisions to follow. This had been touched on buy the other responses. There are plenty of standards the are defacto because companies have published them and they have been widely adopted across their respective industry and this is goodness, but I'm not sure that it is justification for making it a standard unless it meets the goals and objects of the standard's body that wants to adopt it. I think it would be very divisive to fracture and dilute the momentum that we have finally achieved with the WxS standards, unless there is clearly a need to grow beyond what exists today that can not be achieved by growing WxS in a compatible way. -Steve On 5/6/2013 11:11 AM, Daniel Morissette wrote: I am also of the opinion that single-vendor standards such as KML and this GeoServices REST API are turning OGC into a rubber-stamping organization and this is not what the geospatial community needs. Don't get me wrong, it is good to see these openly published, but the publication should be by their owners (Google and ESRI in those case) and not be rubber-stamped by OGC. What the geospatial community needs is an organization that provides direction around a consistent set of standards that guarantee interoperability between interchangeable software components. The suite of WxS services built over the last 10-15 years is somewhat on the way of achieving this, even if some pieces still do not interoperate as smoothly as we wish. Is OGC trying to tell the world that it no longer believes in WxS? OGC and its members need to decide whether they want the OGC logo to be perceived as the guarantee of interoperability, or just as a rubber-stamping organization with a large portfolio of inconsistent standards. Whether your source is open or closed is out of the question here, so I am not sure that a statement from OSGeo matters unless it is to point at this obvious slippery slope in which OGC is falling (a movement which started with KML a few years ago). Daniel On 13-05-06 3:41 AM, Jeroen Ticheler wrote: All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
All, I've followed this thread with interest, thanks for the insightful discussion. If I can spare my 2 cents, is that the OGC specifications are complex enough already, with differences in behavior in the various versions, that adding another set of competing standards is just going to increase confusion quite a bit, diluting the OGC position as a reference for standards to a point of no return. Several of the ideas in the REST GeoServices are good, yes, there is demand for REST geoservices, and yes, JSON is popular, yet, especially from the point of view of someone that participates to open source communities, it's sort of unbelievable that someone can come and impose something to be a standard as-is, no questions asked. It's ok for it to be a starting point, but to be something that is embraced at large it should be allowed to be pruned and modified to everybody's satisfaction. Also, I'm not sure here, but not building on top of the existing standards it will likely introduce new terminology, making it harder to talk about the services in a way that makes people understand each other. Adding a REST service on top of existing standards, such as WFS (as a new network binding) and GeoJSON would likely lower this risk significantly. About implementing it or not, I cannot speak for the GeoServer PSC, but we are normally open and pragmatic, so I doubt that if someone comes up with an implementation of the ESRI GeoServervices API we'd refuse it, and if it gets enough traction, it might well enter the core functionality. It's more about someone contributing the code, and the overall user community showing appreciation for it, than making a political statement. Cheers Andrea ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
All, being involved in both communities I read this thread with high interest. I agree with the issues raised by Bruce, Jeroen, Daniel, etc. I guess my main issue is adding a competing set of standards within OGC without proper justification and thus weakening the overall position of OGC. cu Stephan On 05/06/2013 05:11 PM, Daniel Morissette wrote: I am also of the opinion that single-vendor standards such as KML and this GeoServices REST API are turning OGC into a rubber-stamping organization and this is not what the geospatial community needs. Don't get me wrong, it is good to see these openly published, but the publication should be by their owners (Google and ESRI in those case) and not be rubber-stamped by OGC. What the geospatial community needs is an organization that provides direction around a consistent set of standards that guarantee interoperability between interchangeable software components. The suite of WxS services built over the last 10-15 years is somewhat on the way of achieving this, even if some pieces still do not interoperate as smoothly as we wish. Is OGC trying to tell the world that it no longer believes in WxS? OGC and its members need to decide whether they want the OGC logo to be perceived as the guarantee of interoperability, or just as a rubber-stamping organization with a large portfolio of inconsistent standards. Whether your source is open or closed is out of the question here, so I am not sure that a statement from OSGeo matters unless it is to point at this obvious slippery slope in which OGC is falling (a movement which started with KML a few years ago). Daniel On 13-05-06 3:41 AM, Jeroen Ticheler wrote: All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for both it and traditional W*S services? Bruce ___ 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] Would you be concerned if the GeoServices REST API became an OGC standard?
On Mon, 06 May 2013 18:24:05 +0200 Stephan Meißl step...@meissl.name wrote: All, being involved in both communities I read this thread with high interest. I agree with the issues raised by Bruce, Jeroen, Daniel, etc. I guess my main issue is adding a competing set of standards within OGC without proper justification and thus weakening the overall position of OGC. Hello all, I share most of the points raised in this discussion, and could not have said them better. There is an agenda item about this topic at next Board meeting (9th of May): http://wiki.osgeo.org/wiki/Board_Meeting_2013-05-09 so I'd like to collect the opinion of as most OSGeo members as possible. Stephan, Adrian: is there an effective way for OSGeo to address a statement to OGC, beside the official requests for comments and our Discuss list? Thanks for your thoughts, Anne cu Stephan On 05/06/2013 05:11 PM, Daniel Morissette wrote: I am also of the opinion that single-vendor standards such as KML and this GeoServices REST API are turning OGC into a rubber-stamping organization and this is not what the geospatial community needs. Don't get me wrong, it is good to see these openly published, but the publication should be by their owners (Google and ESRI in those case) and not be rubber-stamped by OGC. What the geospatial community needs is an organization that provides direction around a consistent set of standards that guarantee interoperability between interchangeable software components. The suite of WxS services built over the last 10-15 years is somewhat on the way of achieving this, even if some pieces still do not interoperate as smoothly as we wish. Is OGC trying to tell the world that it no longer believes in WxS? OGC and its members need to decide whether they want the OGC logo to be perceived as the guarantee of interoperability, or just as a rubber-stamping organization with a large portfolio of inconsistent standards. Whether your source is open or closed is out of the question here, so I am not sure that a statement from OSGeo matters unless it is to point at this obvious slippery slope in which OGC is falling (a movement which started with KML a few years ago). Daniel On 13-05-06 3:41 AM, Jeroen Ticheler wrote: All, Having read this thread I support what has been said by Adrian, Bruce and others. If anything, acceptance of a set of standards that basically replicates what W*S standards already do will confuse customers. Maybe that is exactly what esri hopes to achieve, it definitely doesn't help our (the geospatial community) business. And as Bruce states, it will have serious impact on the OGC credibility. As OSGeo I can imagine that we then decide to start our own standardization process and build a standards brand around OSGeo products. Not a nice perspective, let's hope OGC won't go down that route. Jeroen On 6 mei 2013, at 01:08, bruce.bannerman.osgeo bruce.bannerman.os...@gmail.com wrote: Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hi all, I agree with Andrea. In my opinion OGC should be building upon the WxS specifications, introducing REST and JSON with a round of new major versions. It was already tough for us to explain WxS services to end users for the last 10 years. Adding new service specifications will not help us be convincing, since there will be a new question: which standard should we use and why? Also, as a professional I would not expect customers, organizations and governments paying for implementations of both standards... this will eventually lead to a market split. I cannot believe that OGC would like something like that. Best, Angelos On 05/06/2013 06:45 PM, Andrea Aime wrote: All, I've followed this thread with interest, thanks for the insightful discussion. If I can spare my 2 cents, is that the OGC specifications are complex enough already, with differences in behavior in the various versions, that adding another set of competing standards is just going to increase confusion quite a bit, diluting the OGC position as a reference for standards to a point of no return. Several of the ideas in the REST GeoServices are good, yes, there is demand for REST geoservices, and yes, JSON is popular, yet, especially from the point of view of someone that participates to open source communities, it's sort of unbelievable that someone can come and impose something to be a standard as-is, no questions asked. It's ok for it to be a starting point, but to be something that is embraced at large it should be allowed to be pruned and modified to everybody's satisfaction. Also, I'm not sure here, but not building on top of the existing standards it will likely introduce new terminology, making it harder to talk about the services in a way that makes people understand each other. Adding a REST service on top of existing standards, such as WFS (as a new network binding) and GeoJSON would likely lower this risk significantly. About implementing it or not, I cannot speak for the GeoServer PSC, but we are normally open and pragmatic, so I doubt that if someone comes up with an implementation of the ESRI GeoServervices API we'd refuse it, and if it gets enough traction, it might well enter the core functionality. It's more about someone contributing the code, and the overall user community showing appreciation for it, than making a political statement. Cheers Andrea ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hey Ann, all, On 5/6/13 5:48 PM, Anne Ghisla wrote: Stephan, Adrian: is there an effective way for OSGeo to address a statement to OGC, beside the official requests for comments and our Discuss list? Thanks for your thoughts, Anne Any official statement issued by the OSGeo Board or community on this particular vote should probably be addressed to the 'Voting Members of the OGC Technical Committee' since they are the ones who are taking a position during this vote and deciding whether to accept it or not as an official OGC standard. The statement could be sent via Carl Reed, who is the head of the OGC Technical Committee. He lurks on this list as part of the collaboration agreement between the two communities and can be reached directly at: creed U+0040 opengeospatial.org ciao, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Le dimanche 05 mai 2013 01:05:22, Adrian Custer a écrit : On 5/4/13 6:06 PM, Jody Garnett wrote: Thanks for the background Adrian, do we know of any other parties with implementation plans? -- Jody Garnett The known implementations are listed in the document responding to the 'no' vote. I won't list them here 'till I hear back on the status of these documents as public ( f*^(ing Imaginary Property Rules that won't die). However, you'll be glad to know that GDAL is listed as an implementation in the Processing GeoServices JSON since it can read the JSON file returned from one of the services! Yeah, I somehow remember having implemented this in the OGR GeoJSON driver. But this should not mean in any way that this an official endorsement from the GDAL project for the GeoServices REST API to become an OGC standard. As you know, GDAL core business is to read a lot of stuff that aren't standard in any way, sometimes reversed engineered, sometimes unfortunately completely closed by using proprietary external libraries. This is a pragmatic approach, not an ideological one. ~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] Would you be concerned if the GeoServices REST API became an OGC standard?
Cameron, My personal opinion is that if this proposal was accepted, it would be a bad move for OGC. Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations. I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree). I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings. ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format. With the GeoServices REST API, I think that the approach proposed: - is very divisive for the OGC community. - essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade. - does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software. - will result in confusion within the user community that are trying to utilise 'OGC' services. If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards. I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects. Would you consider implementing the GeoServices REST API within your projects? If you did, would you maintain support for both it and traditional W*S services? Bruce On 05/05/2013, at 7:27 AM, Cameron Shorter wrote OSGeo Community, Currently, voting OGC members are to decide whether to accept the GeoServices REST API as an OGC standard. This is already a contentious issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with voting halted temporally, being reopened again in a few days, and closing 2 weeks after that. [1] I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. If there is sufficient interest, I'll raise this issue with the OSGeo Board, with the intent of drafting a statement on behalf of OSGeo. As background: * The API was initially developed by Esri and implemented on the ArcGIS for Server platform. [2] * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. This effectively means that for most use cases covered by the GeoServices REST API, applications would now have two standards to support. Also, spatial infrastructure programs will be impacted, as OGC compliance won't necessarily equate to interoperability. * Most (all?) current OGC web service standards to date have an Open Source reference implementation, which was often (always?) part funded by OGC testbeds, and open source implementations were tested against proprietary implementations during OGC testbeds. As far as I'm aware, there has been very little up-take from the Open Source community of the GeoServices REST API, and I'm unaware of any testing of non-ESRI applications during OGC testbeds. (Someone may be able to correct me here). [1] https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0 (OGC member login required. Votes counted as at 4 May 2013) [2] http://www.opengeospatial.org/standards/requests/89 ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
OSGeo Community, Currently, voting OGC members are to decide whether to accept the GeoServices REST API as an OGC standard. This is already a contentious issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with voting halted temporally, being reopened again in a few days, and closing 2 weeks after that. [1] I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. If there is sufficient interest, I'll raise this issue with the OSGeo Board, with the intent of drafting a statement on behalf of OSGeo. As background: * The API was initially developed by Esri and implemented on the ArcGIS for Server platform. [2] * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. This effectively means that for most use cases covered by the GeoServices REST API, applications would now have two standards to support. Also, spatial infrastructure programs will be impacted, as OGC compliance won't necessarily equate to interoperability. * Most (all?) current OGC web service standards to date have an Open Source reference implementation, which was often (always?) part funded by OGC testbeds, and open source implementations were tested against proprietary implementations during OGC testbeds. As far as I'm aware, there has been very little up-take from the Open Source community of the GeoServices REST API, and I'm unaware of any testing of non-ESRI applications during OGC testbeds. (Someone may be able to correct me here). [1] https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0 (OGC member login required. Votes counted as at 4 May 2013) [2] http://www.opengeospatial.org/standards/requests/89 -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hi cameron I think ogc is stand as standard body which will home as geoservices Yes, there are several overlap I prefer esri to certified his product withnogc rather make new standarsd in ogc That is dangerous to community On May 4, 2013 5:46 PM, Cameron Shorter cameron.shor...@gmail.com wrote: OSGeo Community, Currently, voting OGC members are to decide whether to accept the GeoServices REST API as an OGC standard. This is already a contentious issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with voting halted temporally, being reopened again in a few days, and closing 2 weeks after that. [1] I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. If there is sufficient interest, I'll raise this issue with the OSGeo Board, with the intent of drafting a statement on behalf of OSGeo. As background: * The API was initially developed by Esri and implemented on the ArcGIS for Server platform. [2] * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. This effectively means that for most use cases covered by the GeoServices REST API, applications would now have two standards to support. Also, spatial infrastructure programs will be impacted, as OGC compliance won't necessarily equate to interoperability. * Most (all?) current OGC web service standards to date have an Open Source reference implementation, which was often (always?) part funded by OGC testbeds, and open source implementations were tested against proprietary implementations during OGC testbeds. As far as I'm aware, there has been very little up-take from the Open Source community of the GeoServices REST API, and I'm unaware of any testing of non-ESRI applications during OGC testbeds. (Someone may be able to correct me here). [1] https://portal.opengeospatial.**org/?m=projectsa=view** project_id=82tab=5subtab=0https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0 (OGC member login required. Votes counted as at 4 May 2013) [2] http://www.opengeospatial.org/**standards/requests/89http://www.opengeospatial.org/standards/requests/89 -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com __**_ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/discusshttp://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On Sat, May 4, 2013 at 11:46 AM, Cameron Shorter cameron.shor...@gmail.com wrote: I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. My current concern is that the standards documents are in a bunch of Microsoft Word files. And a bunch of Microsoft Word files that *crash* my current version of OpenOffice Oh the comedy of open standards being written using non-open file formats[1] The ironic comment of standards are great - lets have more of them possibly applies here. In terms of open source implementations, the google search geoservices rest api github doesn't find much, so I suspect the open source community is happy with its web APIs already. These guys: https://github.com/WSDOT-GIS/Traveler-Info-GeoServices-REST appear to be implementing a GeoServices REST endpoint for their system, maybe they'd be willing to refactor their code out and develop it as a reference server implementation? But oh dear it seems to be written in C#. I'm not sure what the term 'reference implementation' means here. Any difference in behaviour between an implementation and the spec is a bug with the implementation, yes? For that I don't think it matters if the reference implementation is open source or a black box - that's irrelevant to its compliance with the standard. However, a freely-available implementation does make it easier (and in some cases, possible) to write code that works practically. I wouldn't like to write a GeoServices client without a server to test it against. Without it my option is to check my client request is correct by comparing it with the standards document (in that unreadable Word document). Imagine if the authors of the first web browsers hadn't had http servers to actually test against? The advantages of an open source reference implementation are also the usual advantages of open source that we've been banging on about for years. Mismatches between open source implementations and standards docs can be fixed in minutes and released, and users don't have to wait six months for the next product update release, for example. Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. Barry [1] yeah this is probably wrong and MS got their file formats certified 'open' somehow... blah blah court case blah blah ISO voting blah blah ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design). The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. The name of the standard 'GeoServices REST API' and the services are controversial for many reasons. The 'GeoServices' moniker is non-descript (many OGC standards are for geospatial services) and matches the current ESRI marketing terminology. 'REST' is a buzzword and implies a lot of design work which has not been done (and is happening elsewhere at the OGC); furthermore, if REST is about the design of a service's behaviour (that the service acts based on the transfer of representations of resources), then the word does not relate to an 'API'. Finally, the 'API' word does not really describe the standard which is describing a number of services and data exchange formats. The names of each service, e.g. either 'Map Service' or 'GeoServices Map Service' is problematic: how do we make sure that people know the difference between the 'OGC Web Map Service' and the 'OGC GeoService Map Service' ? However, despite these criticisms,
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Il 04/05/2013 18:43, Adrian Custer ha scritto: Which brings us to OSGeo and what useful contribution it could make to the debate. Simply rehashing the issues above is not going to be useful to anyone. If new ideas arise, or a large, common position emerges on the issue, I'd be glad to inject them into the OGC discussion. I suspect there is at least a week before voting resumes, although the rules going forwards are not yet clear. Adrian, your overview is very helpful. From where I stand, there are three reasons to push for a no to the proposed standard, all touched in your or Cameron's message: 1. disrespect for an existing, widespread, appreciated standard: GeoJSON 2. no open source reference implementation 3. vote was already suspended multiple times, showing a lack of agreement about this standard Points 1 and 2 are part of the OSGeo mission IMHO. Thank you steko -- Stefano Costa http://steko.iosa.it/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hey Barry, There is no useful concept of a 'reference implementation' at the OGC. The things the OGC calls 'reference implementation' are actually example testing implementations. The word was incorrectly adopted by the testing group (pushed by those with commercial concerns). The testing group now wants to have multiple 'reference implementations' showing they are not really a 'reference' in the common understood meaning. I am trying to get the testers to change the terminology to avoid the semantic conflict with the general meaning of 'reference implementation.' Critically, none of the implementations were vetted by the groups defining the actual standards documents so there is little relation between the implementation and the standard. It therefore makes little sense to think of 'reference implementations' at the OGC. As far as GeoServices REST, the default reference implementations are ESRI's since the document is merely defining how those implementations work. ~adrian On 5/4/13 1:27 PM, Barry Rowlingson wrote: On Sat, May 4, 2013 at 11:46 AM, Cameron Shorter cameron.shor...@gmail.com wrote: I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. My current concern is that the standards documents are in a bunch of Microsoft Word files. And a bunch of Microsoft Word files that *crash* my current version of OpenOffice Oh the comedy of open standards being written using non-open file formats[1] The ironic comment of standards are great - lets have more of them possibly applies here. In terms of open source implementations, the google search geoservices rest api github doesn't find much, so I suspect the open source community is happy with its web APIs already. These guys: https://github.com/WSDOT-GIS/Traveler-Info-GeoServices-REST appear to be implementing a GeoServices REST endpoint for their system, maybe they'd be willing to refactor their code out and develop it as a reference server implementation? But oh dear it seems to be written in C#. I'm not sure what the term 'reference implementation' means here. Any difference in behaviour between an implementation and the spec is a bug with the implementation, yes? For that I don't think it matters if the reference implementation is open source or a black box - that's irrelevant to its compliance with the standard. However, a freely-available implementation does make it easier (and in some cases, possible) to write code that works practically. I wouldn't like to write a GeoServices client without a server to test it against. Without it my option is to check my client request is correct by comparing it with the standards document (in that unreadable Word document). Imagine if the authors of the first web browsers hadn't had http servers to actually test against? The advantages of an open source reference implementation are also the usual advantages of open source that we've been banging on about for years. Mismatches between open source implementations and standards docs can be fixed in minutes and released, and users don't have to wait six months for the next product update release, for example. Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. Barry [1] yeah this is probably wrong and MS got their file formats certified 'open' somehow... blah blah court case blah blah ISO voting blah blah ___ 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] Would you be concerned if the GeoServices REST API became an OGC standard?
Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. https://code.google.com/p/libkml/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) Adrian, Do you have by chance a link to the response to comments ? I did write comments on the documents during the public comment period, but didn't remember seeing any response posted on the OGC list where I posted my comments... Best regards, Even ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On Sat, May 4, 2013 at 9:43 AM, Adrian Custer acus...@gmail.com wrote: The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. - To elaborate on the unequal footing phrase above: One additional aspect of the government side of this equation is that for several years there has been a trend (similar to Microsoft products) in getting the ESRI architecture adopted as a GIS software standard within government IT enterprise contexts. This then requires agencies to transition to use of the ESRI platform exclusively for geospatial work. Projecting into the future, if there were 2 competing OGC service types and ESRI were to drop support for the older W*S family of OGC services (or merely push support for them out of the core packages and into an expensive interoperability add-on), this would place many agencies in a situation of only being able to serve the newer standards, effectively killing the older standards within those contexts... ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Adrian, Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help. I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening. On 05/05/13 02:43, Adrian Custer wrote: Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design). The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. The name of the standard 'GeoServices REST API' and the services are controversial for many reasons. The 'GeoServices' moniker is non-descript (many OGC standards are for geospatial services) and matches the current ESRI marketing terminology. 'REST' is a buzzword and implies a lot of design work which has not been done (and is happening elsewhere at the OGC); furthermore, if REST is about the design of a service's behaviour (that the service acts based on the transfer of representations of resources), then the word does not relate to an 'API'. Finally, the 'API' word does not really
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On 5/4/13 6:06 PM, Jody Garnett wrote: Thanks for the background Adrian, do we know of any other parties with implementation plans? -- Jody Garnett The known implementations are listed in the document responding to the 'no' vote. I won't list them here 'till I hear back on the status of these documents as public ( f*^(ing Imaginary Property Rules that won't die). However, you'll be glad to know that GDAL is listed as an implementation in the Processing GeoServices JSON since it can read the JSON file returned from one of the services! ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On 5/4/13 6:21 PM, Cameron Shorter wrote: Adrian, Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help. Cheers. I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening. I have not taken much detailed interest in these services ever since it became clear that they had no interest in working with the WMS folk and that nothing could be changed to improve the standard. (They couldn't even fix dates to be in the unambiguous ISO 8609 format -MM-DD since that would break 'backwards compatibility'!) My understanding is that these services are built on what I call the Flat Feature Model which are Features with single geometries made up of 2D, linear structures (points, lines, or polygons) and a list of primitive value attributes (the shapefile data model). (Simple Features, it turns out, are not so simple; they can only have a single geometry but that geometry can be multidimensional and complex while the attributes can be arbitrarily complex and in various namespaces. So 'Flat Features' are what I used to think 'Simple Features' were.) There is surely a need for very simple geospatial services which are limited to the Flat Feature Model. That is why we have all been working on rewriting the W*S standards in modular form to allow for very simple implementations while also enabling more complex implementations, experiments, and easier fixes. The ESRI effort, had it been designed to help users, could easily have plugged into the efforts going on in the various W*S groups. Instead, it has so far been a complete drain on my time. ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
TC Haddad wrote: - To elaborate on the unequal footing phrase above: One additional aspect of the government side of this equation is that for several years there has been a trend (similar to Microsoft products) in getting the ESRI architecture adopted as a GIS software standard within government IT enterprise contexts. This then requires agencies to transition to use of the ESRI platform exclusively for geospatial work. Projecting into the future, if there were 2 competing OGC service types and ESRI were to drop support for the older W*S family of OGC services (or merely push support for them out of the core packages and into an expensive interoperability add-on), this would place many agencies in a situation of only being able to serve the newer standards, effectively killing the older standards within those contexts... Of course, isn't it funny, that it's getting harder and harder to find ESRI stuff anywhere, government or not. Lot's of enterprise Google Earth, and Google Maps Engine though. Of note: I recently moved from the DoD world to the transit world. I expected to find a lot of fleet management software built on top of ESRI tracking server. Nope, everything uses Google Maps. Even the aircraft tracking stuff that used to run on ESRI seems all to be Google based these days. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
