-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The OGC API process is fast or slow? #1
Comments
Yet, at the same time, there are things that have been submitted a long time ago for consideration, and are still not integrated by the unifying OGC API Common, slowing down the development of all standards depending on it, and causing a lot of redundant discussions across SWGs. For example, the
I find that, by acting quickly and not waiting too much after Common to "officially" publish definitions, OGC API Features was able to actually propose many parameters that created a common ground for discussion and consideration by other standards. Although definitions do not align "perfectly", they have somewhat of a similar naming, representation and intention, which greatly limits discrepancies between SWG due to many people not talking to each other and coming up with their own custom properties each time. |
I've created a Wiki page on the OGC API - Common repo to keep track of the https://github.com/opengeospatial/ogcapi-common/wiki/Table-of-extensions-to-the-JSON-Schema-vocabulary |
@jerstlouis Please create a ticket about |
Actually, I'm not sure that accelerating the process of creating standards is a good idea.
In OGC API Common we believe that going too fast in OGC API Features ignoring the possibility to create a common backend where all the other APIS could grow, is creating all sorts of small problems that could be solved by a slowing down for a moment and thing about the big picture.
The text was updated successfully, but these errors were encountered: