Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?

2013-05-06 Thread Jeroen Ticheler
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?

2013-05-06 Thread Volker Mische
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?

2013-05-06 Thread Daniel Morissette
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?

2013-05-06 Thread Basques, Bob (CI-StPaul)
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?

2013-05-06 Thread Stephen Woodbridge
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?

2013-05-06 Thread Andrea Aime
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?

2013-05-06 Thread Stephan Meißl
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


[OSGeo-Discuss] 2012 Annual Report Participation

2013-05-06 Thread Landon Blake
I wanted to send out a brief thank you to everyone that wrote and submitted
an annual report item for last year. There is double or triple the number
of report items this year when compared to last year.

Needless to say, I'm running behind with all of the extra content that
needs to be reviewed and edited this year compared to last year. (This is a
great problem to have.)

I'm striving to have something put together, at least in draft form, by the
end of May.

Thank you again to everyone that submitted this year. It really means a lot
to me personally that you took the time away from your programming and
other efforts to put together a contribution.

Landon
OSGeo Journal Editor
___
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?

2013-05-06 Thread Anne Ghisla
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?

2013-05-06 Thread Angelos Tzotsos

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?

2013-05-06 Thread Adrian Custer

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