List of public end-points

[hylkevds]

This thread is now just for reporting new services or updating existing ones.
The actual list of public end-points is at PublicEndPoints.md

Hi All,

In a recent discussion the question came up if we could make a list of public end-points. This would be very useful for giving demos and trying out the SensorThings API.

How would we organise such a list? Some relevant aspects:

• One big table / multiple tables
• Country / region information
• Domain information
• Publisher
• URL
• Writeable by all (sandbox services)
• Supported version(s)
• Used implementation

What do you all think?
Here are some quick examples to help the discussion (Markdown in issues doesn't support tables):

Sandbox Services

| Owner | access | version | Endpoint URL
| Fraunhofer IOSB | CRUD | 1.1 | https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/
| SensorUp | CRUD | 1.0 | http://scratchpad.sensorup.com/OGCSensorThings/v1.0

Germany

| Owner | Domain | Info | Endpoint URL
| Freie und Hansestadt Hamburg, Landesbetrieb Geoinformation und Vermessung | Smart Cities | info | https://iot.hamburg.de/v1.1/

United Kingdom

| Owner | Domain | Info | Endpoint URL
| British Geological Survey | Ground water | info | https://sensors.bgs.ac.uk/FROST-Server/v1.1

[sgrellet]

Great idea, I'd do it by domain (as opposed to by country/region) as it may reasure new comers their domain is covered.
And as, most of the time, you define a 'pattern' to match ST API to your domain terms/practices.
I tested this approach in French and it proved really helpful (see here : https://github.com/INSIDE-information-systems/SensorThingsAPI).

+1 on the rest of the item

I'd add a date info related to each implementation (available YYYYMMDD) to anticipate the fact that, over time, some endpoints may not be available anymore (ex : R&D projects)

[ksonda]

Just to keep track, I have several in this viewer https://sta-client.internetofwater.dev

[sgrellet]

@ksonda , great ! : you can add this one in your viewer -> French Surface Water Quality bank (snapshot from end of 2018) : https://sensorthings-wq.brgm-rec.fr/FROST-Server/v1.0 . That may be of interest for the internet of water activities.

[hylkevds]

Per domain sounds good. Which domains would we want?

@ksonda: is there a way to see which endpoints are being used on that site? Since the endpoints are not accessed directly by the browser, but by your server.

Sandbox Services

Owner	access	version	Endpoint URL
Fraunhofer IOSB	CRUD	1.1	https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/
SensorUp	CRUD	1.0	http://scratchpad.sensorup.com/OGCSensorThings/v1.0

Smart Cities

County	Owner	Domain	Info	Endpoint URL
Germany	Freie und Hansestadt Hamburg, Landesbetrieb Geoinformation und Vermessung	Smart Cities	info	https://iot.hamburg.de/v1.1/

Water

County	Owner	Domain	Info	Endpoint URL
UK	British Geological Survey	Ground water	info	https://sensors.bgs.ac.uk/FROST-Server/v1.1
France	BRGM	Surface water quality	info	https://sensorthings-wq.brgm-rec.fr/FROST-Server/v1.0

[ksonda]

They're here, but if you want to add a table in markdown document I can PR into it with the metadata you put above.

https://github.com/internetofwater/sta-dashboard/blob/main/endpoints.json

[hylkevds]

I've added the page to the repository: https://github.com/opengeospatial/sensorthings/blob/master/PublicEndPoints.md

[nbrinckm]

I have a question that is a bit related to the discussion of public STA endpoints - but is not really about the entries there.

It is more about how something like terms of services can be embedded in the STA itself.

For example in the Get Capabilities request of the geoserver (as one implementation of WMS) there can be an "AccessConstraints" tag within a service description (for example https://map-services.gfz-potsdam.de/geoserver/wms?service=WMS&version=1.1.0&request=GetCapabilities).

I honestly didn't find something similar yet. And as I also don't see those in the public instances here, I wonder a bit, if there is already a (good) way to handle it.

I think STA-Plus added something about licenses etc - but those are more bound to specific parts of the data & not the server as a whole.

My current best bet would be a small extension (for the FROST) in this case that will add AccessConstraints entity type (and those only manageable for an adminstrator of the server).

[nbrinckm]

Reading #4 it seems that there was already some discussion about it.
Regarding to adding conformance classes it seems that the capabilities & extensions are handled here in a nice way.

I can imagine to handle the access constraints / terms of use in a similar way. But it would be nice if there would be an explicit best practice to follow.

[hylkevds]

Yes, the index document is the place for this additional information. What is needed at this point is a best practice for how to put the various types of data in the index page.
I guess taking the service information from existing services would be a good start.