search

kadaster-labs / sensrnet-home

Home of the SensRNet - The Dutch National Sensor Registry Network
Other
15 stars 7 forks source link

Excel template tbv bulk opvoer uitwerken en publiceren #176

Closed marcvanandel closed 2 years ago

marcvanandel commented 3 years ago

(incl. FME script?)

Samen met @CelineJansen (Gemeente Eindhoven), Gemeente Den Bosch en ... ?

CelineJansen commented 3 years ago

Hierbij een eerste poging voor een FME script om in bulk sensoren op te voeren middels de API. Mijn aanpak is echt een eerste test en kan/moet nog worden uitgebreid. De bijgevoegde Excel file kan je vullen als input.

Ik neem nu aan dat er telkens sprake is van 1:1 relaties. Dus 1 device, met 1 sensor en 1 datastroom. Voor de observation goal heb ik een testje geschreven die ook te koppelen zou moeten zijn binnen 1:n, maar dit heb ik nog niet getest en dus niet verbonden in de flow.

SensorenRegisterAPI_DraftEindhoven.zip

CelineJansen commented 3 years ago

Verder hierbij ook alvast een concept van de inventarisatielijst die binnen de organisatie te delen is (incl. alvast wat minimale voorbeeldjes). Lijst met definities op GitHub (https://github.com/kadaster-labs/sensrnet-home/pull/169) en pull request van de waardenlijsten (https://github.com/kadaster-labs/sensrnet-home/blob/main/docs/Definitions.rstt) zijn hier nog niet in verwerkt.

SensorenregisterInventarisatieLeeg_Concept.xlsx

CelineJansen commented 3 years ago

Let op: Zowel bovenstaand FME script als de inventarisatielijst zijn dus wel echt nog concepten en nog geen volledige eind-producten. Laat het vooral weten wanneer jullie aanvullingen hebben, dan kunnen we dit verder afwerken en verfijnen!

CelineJansen commented 3 years ago

De nieuwste versie van mijn poging tot het maken van een decentrale inventarisatielijst tbv bulkopvoer staat in de bijlage. Als iemand hier toevoegingen op heeft, dan graag.

Stand van zaken unitOfMeasurement en obervedArea? Zoals ik al eerder heb aangegeven, lijkt het me handig om alle attributen die we willen weten zo veel mogelijk in een keer uit te vragen. Daarom kan ik hier intern pas mee aan de slag wanneer er meer duidelijk is over de gewenste aanlever vorm van unitOfMeasurement (op basis van een keuzelijst misschien) en obervedArea (polygoon op basis van Lat,Lon in WKT formaat misschien?). Staat het nog concreet op de planning om hierover te beslissen?

Waarom is Omschrijving sensor verplicht en naam ook? Naam verplicht lijkt me voldoende, in de omschrijving kan je dan vervolgens bijzonderheden kwijt wanneer dit relevant is.

Is ResultTime / Datafrequentie verplicht en in welke vorm dient dit attribuut geleverd te worden? Klopt het bij de definitions (https://github.com/kadaster-labs/sensrnet-home/blob/bb9baa780efd8c61f83c3abc516a0e9682128976/docs/Definitions.rst), dat wanneer er staat dat een attribuut in de MVP staat, deze ook op te voeren is? ResultTime / Datafrequentie bijvoorbeeld, zit nog niet in de documentatie van de API geloof ik (https://demo.sensorenregister.nl/api/#/Sensor/SensorController_registerSensor), maar staat wel in de definitions als zijnde onderdeel van de MVP. Dit is volgens mij ook zo voor BaseObjectid / Extern object-id. Wanneer deze inderdaad toch al ingevoerd kunnen worden, hoor ik graag op welke manier.

SensorenregisterInventarisatieLeeg_Concept.xlsx

kad-bloemy commented 3 years ago

UnitOfMeasurement is overgenomen uit SensorThingsAPI. Daarin staat: "A JSON Object containing three key-value pairs. The name property presents the full name of the unitOfMeasurement; the symbol property shows the textual form of the unit symbol; and the definition contains the URI defining the unitOfMeasurement. The values of these properties SHOULD follow the Unified Code for Unit of Measure (UCUM). " Dit is een verplicht veld. _"Note: When a Datastream does not have a unit of measurement (e.g., a OMTruthObservation type), the corresponding unitOfMeasurement properties SHALL have null values."

Een voorbeeld uitwerking hiervan is: "unitOfMeasurement": { "name": "degree Celsius", "symbol": "°C", "definition": "http://unitsofmeasure.org/ucum.html#para-30"

Een keuzelijst lijkt geen optie gezien het aantal meeteenheden.

kad-bloemy commented 3 years ago

Zie nieuwste comment #196 over SI-eenheden.

marcvanandel commented 3 years ago

Issue afronden door

kad-bloemy commented 3 years ago

Is dit de laatste versie? https://github.com/kadaster-labs/sensrnet-home/files/6624715/SensorenregisterInventarisatieLeeg_Concept.xlsx Dan neem ik deze op op de Overview pagina

CelineJansen commented 3 years ago

SensorenregisterInventarisatieLeeg_Concept.xlsx Deze is nieuwer en net iets anders volgens mij. Let op: wel dus nog incompleet ivm de observedArea en unitsOfMeasurement.

kad-bloemy commented 3 years ago

Heb een pull request gemaakt om de file te uploaden, maar misschien is dat niet nodig. Als de file is ge-uploaded dan zet ik hem op de Overview pagina

CelineJansen commented 3 years ago

Openstaande Issues 20-09-2021.pptx Status 22-09-2021:

marcvanandel commented 2 years ago

@CelineJansen , is de laatst toegevoegde Excel nog steeds de laatste versie waar jij mee werkt?

CelineJansen commented 2 years ago

Nee, scherp: dit is mijn laatste versie (kleine wijziging voor observation area en unit of measurement (moet waarschijnlijk later nogmaals gewijzigd)): SensorenregisterInventarisatieLeeg.xlsx.

kad-bloemy commented 2 years ago

Hoi Celine, Ik was al bezig met de waardelijsten: Waardelijst_Wildcards.xlsx Waardelijst_Thema.xlsx Waardelijst_Sensortypes.xlsx

Staan ook in mijn eigen branch: https://github.com/kadaster-labs/sensrnet-home/tree/gebruikerdoc/docs Ik denk dat je daarvoor geautoriseerd moet zijn, maar daar kan ik niet voor zorgen;(

CelineJansen commented 2 years ago

Super handig Yolanda! Neem je daarbij ook mee of de waardes met de schrijfwijze zoals ze in jouw lijsten staan werken als input voor de API? (Zo nee, dan moeten we daar los nog een testje voor doen).

CelineJansen commented 2 years ago

Hierbij twee FME scripts: een verbeterde versie voor opvoer met 1:n mogelijkheden, alsook een script voor bulk verwijderingen. Inclusief templates die gebruikers kunnen vullen als input voor de scripts.

LET OP: vat dit niet op als een afgerond eindproduct dat bruikbaar is voor een grote variëteit aan productie toepassingen (daarvoor ontbreekt de nodige error-handling bijvoorbeeld, de scripts zijn nog niet fool-proof). Voor de pilot is dit een goede basis lijkt me, maar wees kritisch en controleer je resultaten. Ik hoor het graag wanneer er aanvullingen of opmerkingen zijn.

Documentatie in de handleiding staat hier: https://github.com/kadaster-labs/sensrnet-home/issues/263 vanaf pagina 14 gaat het over het gebruik van de API en de scripts.

FME scripts bulk Opvoer en Verwijderen.zip

marcvanandel commented 2 years ago

De handleiding is opgeleverd en daarin is de laatste versie van de scripts en templates opgenomen 😉

CelineJansen commented 2 years ago

Heb inmiddels ook een basis staan voor het bewerken van gegevens en het ophalen van een stand voorafgaande hieraan.

Let op: deze scripts zijn wederom puur ter inspiratie. Het betreft geen afgewerkte eindproducten: ze zijn niet uitvoerig getest, er wordt uitgegaan van een valide input (geen/nauwelijks fout afhandeling), en e.e.a. berust op enkele aannames (bijvoorbeeld dat er niet datastromen met precies dezelfde attributen bij een sensor kunnen horen). Praktijktest zullen uitwijzen waar bijgeschaafd moet worden. Er volgt nog een nieuwe versie voor het opvoeren van een ObservedArea op de kaart wanneer dit mogelijk is met de API van de demo-omgeving (https://github.com/kadaster-labs/sensrnet-registry-frontend/issues/192). De basis hiervoor heb ik wel al staan maar daar kan ik nog helemaal niks aan testen en wacht ik dus nog even mee.

Scripts en input SensorenAPI.zip