[pygeoapi] pygeoapi as productive tool

[Benjamin Webb]

Wolfgang,

Building on the responses from the other pygeoapi contributors, I can confirm that we use pygeoapi in support of the Internet of Water project. We primarily deploy pygeoapi on Google Cloud Platform as an isolated container on Cloud Run as well as running pygeoapi with remote backends such as Cloud SQL, ESRI Feature Service, Socrata, and SensorThings API.

I understand pygeoapi's reference implementation status to refer primarily to the ease at which you can deploy performant and certified OGC API services from various backends.

I do not have much experience with Oracle Spatial, but I echo Francesco's words. The provider plugin architecture makes it easy to write a provider for your backend - if that backend is not already supported by the provider plugins in pygeoapi core.

Thanks,
Ben


Ben Webb

Software Developer

Center for Geospatial Solutions<https://www.lincolninst.edu/center-geospatial-solutions>

Lincoln Institute of Land Policy<https://www.lincolninst.edu/>

303.681.1420 (mobile)


________________________________
From: pygeoapi <pygeoapi-bounces at lists.osgeo.org> on behalf of Francesco Bartoli <xbartolone at gmail.com>
Sent: Wednesday, November 23, 2022 8:46 AM
To: pygeoapi at lists.osgeo.org <pygeoapi at lists.osgeo.org>; Tinkl Wolfgang <Wolfgang.Tinkl at ama.gv.at>
Subject: Re: [pygeoapi] pygeoapi as productive tool

Dear Wolfang,

thank you for your feedback! It is very appreciated.

I have seen in the last two years many organizations which are now using it in production to support the modern OGC API. I strongly suggest to run pygeoapi in a cloud infrastructure so you can adopt all the OOTB architectural solutions to scale it up. I have experienced different paradigms on AWS but I’m pretty sure you can achieve the same from other providers. Also, since the configuration of pygeoapi is very flexible you can even combine and aggregate on purpose different pygeoapi microservices with few collections (even just one!) into an API gateway that serve the whole infrastructure.

I don’t have much to say about Oracle Spatial but the OGR provider should help to streamline feature collections from that database. Otherwise you could start developing a native Oracle Spatial backend provider (it shouldn’t be so hard) or ask the support from our service providers https://pygeoapi.io/community/service-providers/.

Hope this helps.

Kind Regards,
Francesco
Il 23 nov 2022, 13:40 +0100, Tinkl Wolfgang <Wolfgang.Tinkl at ama.gv.at>, ha scritto:

Dear pygeoapi/osgeo Community,



First of all: thank you very much for this implementation of the OGC API Feature standard.



We are planing to use pygeoapi in a large scale productive environment as OGC API Feature REST service provider.

Questions:

How fit is pygeoapi for productive use, and how much is it ‘just’ a reference implementation? What would you suggest for a good productive use?

Does someone have any experience with using ORACLE Spatial data as data source?



Thank you, best regards,

Wolfgang









Mit freundlichen Grüßen,



DI Wolfgang Tinkl

II/6/18 - INVEKOS Erfassung und Internet

Agrarmarkt Austria

Dresdner Straße 70

1200 Wien

Tel.: +43 050 3151-4712

E-Mail: wolfgang.tinkl at ama.gv.at<mailto:wolfgang.tinkl at ama.gv.at>

Internet: www.ama.at<http://www.ama.at/>



Der Austausch von Nachrichten mit o. a. Absender via E-Mail dient ausschließlich Informationszwecken und ist rechtlich nicht bindend.



Der Austausch von Nachrichten mit o.a. Absender via E-Mail dient ausschließlich Informationszwecken und ist rechtlich nicht bindend.

_______________________________________________
pygeoapi mailing list
pygeoapi at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pygeoapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20221123/4fd61ddb/attachment-0001.htm>