Hello Everyone,
Last time we talked about the OGC SensorThings API standard, and we explained how the main models are contributing. After a load of overwhelming requests (If we ignored reality for a while), let’s talk about what the extended features of istSOS4 are that made using the OGC Standard much easier.
When we update any entity in our system, we actually need to know the entire history of the entity, its measurement unit, its location, and we need to know who edited it, when, why, and more details. So we have the Commit entity, which is as important as the Datastream. Any change in a resource, for example (POST/PUT/PATCH/DELETE), will require you to insert a commit message as a custom header in the API request, and it will save it in the database. Think of it like Git but for Geospatial Data. And of course, we have the User who can log in to the system and use the entire features of istSOS4. Each user has their own policies that will be implemented if someone worked on an RBAC system, where each user will have their own policies related to CRUD operations on the entities.
When you bring the observations to the table, you get a value, but you don’t know if that value is a string or a number, or any more info about it. Like if, let’s say, the result of the observation is 1, do you know its type? A number, string, boolean, cry for help?
So the columns of types are provided in the Observation table like resultNumber, resultString, resultBoolean, resultJson, and resultQuality.
Did you ever ask yourself: if an observation was measured in the field, then uploaded 3 days later because the sensor was offline, what’s the “real” timestamp? Of course, it will not be the time that the record was created. So we have phenomenonTime, the actual real-world timestamp when the observation was measured, completely separate from when the record hit the database. The record has its own validity, because the record could be changed because of commits or changes.
And I’m not speaking about the observation only, I’m talking about any entity. The commit will change the properties of the entity, and for a scientist or user who needs to track the snapshots, the istSOS4 extension provides views in our database, so you can see any snapshot of the metadata of any entity with its period or duration. The duration is systemTimeValidity, which gives you the period that this snapshot is valid.
I had a small mistake in the past topic, when I said that Network is part of the OGC Standard, but actually it’s part of the istSOS4 extension.
So my question to you here, what case have you used time-travel queries for? Like debugging, auditing? Tell us your case in the comments below.
Of course, there are other extensions and other things to find inside the extension, but I covered the main things, so you can start contributing, you have no excuse for not understanding the project.
If you have any feedback, don’t hesitate to give it. And if you have a topic that you want me to talk about, put it in the comments, and I will make a topic about it ASAP.
See you soon.