TK 452 N 266 1 (18) AG3 AG3_rapport.doc Projektdokument TK452 Arbetsgrupp 3 Under arbete
2 Innehållsförteckning 1 Inledning... 3 1.1 SYFTE... 3 1.2 BAKGRUND... 3 2 Genomförande... 3 3 Resultat... 14 3.1 IDENTIFIERING AV DATAPRODUCENTER OCH DATAFÖRVALTARE... 14 3.2 IDENTIFIERING AV DE OLIKA PARTERNAS ROLLER FÖR DATAUTBYTE... 14 3.2.1 Datasamverkan mellan LMV och SMHI... 14 3.2.2 SMHIs ansvarsområde inom testet... 14 3.2.3 Lantmäteriets ansvarsområde inom testet... 14 3.2.4 Vattenmyndighetens ansvarsområde inom testet... 14 3.3 KRAVBILD FRÅN OLIKA INTRESSENTER... 15 3.4 GRÄNSSNITT MELLAN STANDARDENS SCHEMAN OCH BEFINTLIGA DATAMÄNGDER... 15 3.5 TEST AV DATAUTBYTE AV EN DEFINIERAD DATAMÄNGD MED HJÄLP AV XML/GML... 15 4 Bilaga... 1
3 1 Inledning 1.1 Syfte Svensk standard för SS 63 70 08 för att verifiera att schemana i SS 63 70 08 fungerar i verkligheten. Eftersom testerna startade innan xml-filerna var producerade har gruppens arbete mer utgjorts av praktiska moment för att testa överföring mellan Lantmäteriet och SMHI samt Lantmäteriet och Vattenmyndigheterna. 1.2 Bakgrund SIS tekniska kommitté för ytvattenstandard (TK 452) har initierat testet av standarden. En arbetsgrupp (AG3) för testet har inrättats inom TK 452 med Kerstin I Johansson, Lantmäteriet (sammankallande), Anders Gyllander, SMHI och Erik Lundborg, Vattenmyndigheten. Omfattning för arbetsgruppen AG3 inom TK 452: Identifiering av dataproducenter, dataförvaltare och andra relevanta intressenter inom detta område i Sverige Identifiering av de olika parternas roller för datautbyte Klargörande av krav från SMHI och Vattenmyndigheterna på Lantmäteriets datamängder Utarbetande av gränssnitt genom mappning mellan standardens scheman och befintliga datamängder Test av datautbyte av en definierad datamängd med hjälp av XML/GML 2 Genomförande Testet gjordes på en databas över Vindåns avrinningsområde. Databasen är ett urval ur Lantmäteriets Översiktskarta som kompletterats med nätverk och objektifierats av SMHI. Ytvattenstandardens applikationsschema användes för att skapa benämningar på attribut och objekt enligt denna. För att kunna testa utbyte via GML 3.1.1, simple feature GML har vi skapat UUID för alla objekt i klasserna vattenytor, rinnsträckor, vattenplatser. Dessutom har vi lagt till en strandlinje för sjöarna i testdatabasen för att kunna utföra test av relationer. De nyskapade UUID-värdena överfördes till SMHI:s data via en textfil med fälten UUID och RSTID. SMHI:s RSTID är ett internt unikt ID för alla nätverksbildade hydrologiska objekt. Därefter gjordes modifieringar i testdatabasen enligt följande testschema. Test att överföra en förändring vilken kan jämföras med en delleverans eller uppdatering
4 2.1 Förändradgeometri Fig. 2.1a Originalgeometri Fig 2.1b Förändrad geometri Typen av förändringar sker i standarden genom en flaggning i attributet change. För denne företeelse kommer förändringen att var en MODIFY. Observera att UUID inte har förändrats men det vi ser är en ny version av företeelsen. Fig 2.1c Attribut i förändrad företeelse
5 2.2 Dela upp ett objekt i två nya objekt Fig 2.2a Uppdelning av sjöyta i två nya ytor Delat en sjö i två bassänger och skapat en bassänggräns. Denna operation kräver att alla nya företeelser har egna unika identiteter, UUID. I samband med uppdelningen skapas det dessutom en ny bassänggräns och även nya strandlinjer som även dessa får egna identitet, se fig 2.2b Fig 2.2b Ny bassänggräns samt strandlinje
6 2.3 Lägga till ett nytt objekt Objekt skapas genom att lägga till geometri och tillhörande attribut. När man uppdaterar datasetet läggs all ny data in under XML-tag ADD 2.4 Dela upp en sjö i två mindre sjöar plus vattenplatser och mellanliggande rinnsträcka. Denna operation måste ske i flera steg och kan dessutom utföras på flera olika sätt. Dessa operationer baseras på kombinationer av ADD, MODIFY och DELETE. Som illustration se tabellen i figur 2.4a. I fältet CHANGE ses kombinationer av tidigare nämnda förändringar. De flesta operationer genererar ett nytt UUID dock inte alla som exempelvis MODIFY. Fig 2.4a Attributtabell för förändrade objekt Fig 2.4.b Sjö innan uppdelning i nya företeelser
7 Fig 2.4c De två resulterande sjöarna samt mellanliggande rinnsträcka tillhörande vattenplatser. 2.5 Slå ihop två rinnsträckor eller två sjöar till ett objekt Slå ihop två sjöar till ett objekt. Mellanliggande rinnsträcka kodas om till stomlinje. Två vattenplatser tas bort. Hopslagning görs genom att lägga till en yta utmed rinnsträckan mellan sjöarna, därefter slås alla tre ytor ihop till en. Strandlinjer modifieras genom att delas vid ytgräns, vissa tas bort och nya läggs till för den nya ytan. Se fig 2.5a för ursprungligt utseende samt fig 2.5b för utseende efter förändring.
8 Fig 2.5a Två sjöar samt en rinnsträcka innan sammanslagning
9 Fig 2.5b Ny sammanslagen sjö 2.6 Överföring av data med GML Resultatet från modifieringar i steg 2.1 till 2.5 användes sedan för att skapa enkla GML-filer. Dessa GML-filer skapades i FME, se figur 2.6.a och skickades via e-post till både Vattenmyndigheten och SMHI. Importfunktioner för dessa GML-filer har sedan testats hos dessa båda intressenter. Mellan Lantmäteriet och SMHI testades överföring via GML-filer med programvaran ArcGIS 9.2. På så sätt kunde geometrier och attribut överföras. Vill man dessutom överföra relationer mellan olika företeelser kan detta lösas genom att använda referenser i GML-filen. Detta har dock inte gjorts i detta test. Mellan Lantmäteriet och Vattenmyndigheten testades överföring via GML-filer med programvaran FME. FME står för Feature Manipulation Engine och är tillverkat av Safe Software. Programmet är mycket kraftfullt och tillåter överföring mellan i stort sett alla geografiska- samt databasformat på marknaden. Konvertering mellan olika format sker i ett grafiskt gränssnitt. Arbetsgången går grovt tillväga så att man väljer vilken fil man vill arbeta med och vilket filformat samt koordinatsystem den har. Därefter bygger man upp de förändringar man önskar utföra innan formatöverföringen som i detta fall vill vi exempelvis lägga till SE till SJO_ID. Slutligen väljer man vilket format samt koordinatsystem man önskar exportera till. Fig 2.6a Konvertering mellan shape och GML utgående från SMHI:s databas SVAR. 2.7 Överföring av sjöinformation från SVAR med en enkel mappning av attribut Överföringen av SVAR-data i en accessdatabas har skett med hjälp av XMLmappningsprogramvar. I denna test har vi använt oss av en programvara som heter Altanova Mapforce men det finns ett otal andra leverantörer.
10 Syftet med detta deltest har varit att överföra data från en databas till en annan mottagande databas i form av en XML-fil uppbyggd enligt standardens schema. Arbetsgången har skett i följande steg: Skapa ett mappningsschema för den exporterande databasen Generera XML-fil enligt standardens schema Överföra XML-filen Skapa mappning till mottagande databasstruktur Generera SQL-fil Importera överförd datamängd 2.7.1 Skapa mappningsschema Testet har utgått från en accessdatabas innehållande tabelldata från SMHI:s sjöregister SVAR. Det som önskas är att överföra attribut och geometrier enligt SS637008. Fig 2.7.1a Tabell med sjöinformation från SMHI:s SVAR Första steget är således att mappa mellan SVAR:s struktur och den struktur som är definierad i XML-schema enligt SS637008. För att kunna göra dessa kopplingar användes MapForce och en illustration över detta kopplingsförfarande ses i figur 2.7.1.b.
11 Fig 2.7.1b Koppling mellan SVAR och XML-schema för SS637008 2.7.2 Generering av XML-fil Mappningen i MapForce gör att vi sedan enkel tmed programmets inbyggda funktionalitet kan exportera ut resultatet som en XML-fil helt enligt standardens schema. <?xml version="1.0" encoding="utf-8"?> <GI xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="d:/projekt/tk452/xml_eclips/workspace/ws_xmltest/projekt/tk452/xmlsch ema/xsd/ss637008.xsd"> <dataset> <WS_Lake> <uuid>6de8a1b3d12a954791f22cc6757b7df9</uuid> <phenomenonidentity> <prefix>se</prefix> <number>616114134263</number> </phenomenonidentity> <name>ekholmssjön</name> <position> <pointposition> <position> <coordinate> <Number>1342630</Number> <Number>6161140</Number>
12 </coordinate> <dimension>0</dimension> </position> </pointposition> </position> <area> <value></value> <unit>m</unit> </area> <averagedepth> <value>1.6</value> <unit>m</unit> </averagedepth> </WS_Lake> <WS_Lake> <uuid>426af2f2ffcfe34bafe0818c14d0fbf6</uuid> <phenomenonidentity> <prefix>se</prefix> <number>616141133891</number> </phenomenonidentity> <name>yddingesjön</name> <position> <pointposition> <position> <coordinate> <Number>1338910</Number> <Number>6161410</Number> </coordinate> <dimension>0</dimension> </position> </pointposition> </position> <area> <value>2.1</value> <unit>m</unit> </area> <averagedepth> <value>1.7</value> <unit>m</unit> </averagedepth> </WS_Lake> <WS_Lake> 2.7.3 Överföra XML-filen Den fil som genereras kan sedan enkelt tillhandahållas via en standardiserad webbtjänst som kan svara på direkta anrop eller automatiskt generar filer vid förfrågan. Det går naturligtvis även att skicka filen som en bilaga till ett vanligt mail eller om man så önskar faxa 2.7.4 Skapa mappning till mottagande databasstruktur Den som sedan tar emot XML-filen går tillväga på samma sätt som i avsnitt 2.7.1 men mappar då istället enligt sin databasstruktur. Se figur 2.7.4a
13 Fig 2.7.4a Mappning till mottagande databasstruktur 2.7.5 Generera SQL-fil När mappningen till den mottagande databasen är färdig återstår endast att skapa en SQL-fil för att föra över förändringarna in i den mottagande databasen. SQL-filen har ett utseende enligt nedanstående: INSERT INTO [lakedepth] ([Sjöidentitet],[namn],[djup],[djupenhet]) VALUES ('616114134263','EKHOLMSSJÖN',1,'m') INSERT INTO [lakedepth] ([Sjöidentitet],[namn],[djup],[djupenhet]) VALUES ('616141133891','YDDINGESJÖN',1,'m') INSERT INTO [lakedepth] ([Sjöidentitet],[namn],[djup],[djupenhet]) VALUES ('616235133890','KOPPARGRAVARNA',0,'m')
14 2.7.6 Importera överförd datamängd När väl SQL-filen är skapad sker importen till den mottagande databasen som vilken uppdatering av databasen som helst. Detta är ett standardförfarande och kräver ingen som helst specialkännedom om strukturen på ursprungsdata. 3 Resultat 3.1 Identifiering av dataproducenter och dataförvaltare Vi har identifierat Lantmäteriet och SMHI som de två största dataproducenterna av hydrologiska data. En annan dataproducent, Sjöfartsverket, ansvarar för hydrologiska data i kustregionen och samarbetar med Lantmäteriet om en ny gemensam kustlinje. Vattenmyndigheterna är en viktig mottagare och användare av hydrologiska data. 3.2 Identifiering av de olika parternas roller för datautbyte Vid initiering av test (TK-452-test_060222) framkom följande ansvarsområden för de olika intressenterna. 3.2.1 Datasamverkan mellan LMV och SMHI Samverkan ska gälla vid skapande av UUID Stängningslinje 3.2.2 SMHIs ansvarsområde inom testet Avrinningsområde Djup Tunnlar överledning av vatten Nätverk Kodsättning av vattenförekomster Mottagare av data Koppla data med egna data och attribut 3.2.3 Lantmäteriets ansvarsområde inom testet Geometri för vattenförekomster Stängningslinjen Namn 3.2.4 Vattenmyndighetens ansvarsområde inom testet Kravställare
15 Modellering Mottagare av data Koppla data med egna data och attribut 3.3 Kravbild från olika intressenter Vi har använt resultatet från den enkät som gjordes inom ELIPS POP-Hydro. I denna enkät har SMHI, Vattenmyndigheten och Sjöfartsverket informerat om vilka krav och önskemål de har på Lantmäteriets data. Se bilaga Intressentsamverkan.doc 3.4 Gränssnitt mellan standardens scheman och befintliga datamängder Varje dataproducent/förvaltare måste ha egna gränssnitt mellan sina data och standardens schema, både för export och import av data. Utbyte av data sker via standardens schemafiler. I våra tester med GML har vi varit mest intresserade av att se om vi får med oss all information och anser att det behövs olika mappningsgränssnitt för de olika intressenternas befintliga data. 3.5 Test av datautbyte av en definierad datamängd med hjälp av XML/GML I ytvattenstandarden ingår en xml-fil som har skapats från ytvattenstandardens applikationsschema. Databaser ska struktureras för att information via xml-filer ska kunna utbytas med andra producenter, intressenter och kunder. Rutiner för utbyte av data mellan de olika producenterna måste skapas inom respektive organisation så att utbyte av data kan ske enligt ytvattenstandarden. Vi har testat utbyte av data i GML-format. För att kunna göra inkrementella uppdateringar krävs UUID:n för objekten som ska utbytas. Vi har skapat UUID för testdatabasen på Lantmäteriet i programmet FME och överfört dessa UUID till SMHI:s testdatabas. I ArcGIS 9.2 fungerar import och export av GML-filer smidigt men vi osäkra på hur om hur informationen om ursprungsobjektet ska förmedlas.
Intressentsamverkan.doc Bilaga 1 4 Bilaga Sammanfattning av Elips POP-Hydro Bilaga_8_1_svarssam-intressenter_2006-0830.doc MÅSTEN IDAG Geometrier och skalor Idag används hydrografisk information i skala 1:250,000 för översiktliga beräkningar och för att beskriva vattensystemens utseende. Sjöar och vattendrag ska vara nätverksbildade och därför används SMHI:s version av Bas250. Det ska också finnas information om avrinningsområden och metadata om sjöar. Information om rapporteringsförekomster enligt Vattendirektivet görs i denna skala. Vattenmyndigheterna tar viss information till rapporteringen från kartor i skala 1:100,000 och 1:50,000. Det gäller analys av åtgärder som t ex. kalkning, av små sjöar och vattendrag som inte finns i Översiktskartan. I denna skala används också GSD-Marktäckedata för modellering kopplat till hydrografi. För SMHI är terrängkartan intressant eftersom deras information om avrinningsområden och Svenskt Sjöregister är framtagen i den skalan (den i början av 1980-talet gällande editionen av topografiska kartan). Skalan 1:10,000 används av Sjöfartsverket för NSL insamling men även av övriga intressenter för lokala beräkningar. Storskaligheten är viktig för noggranna, lokala beräkningar. Sjöfartsverket använder även skalor 50,000, 200,000 och 500,000. För SMHI är skalan 1:10,000 användbar vid översvämningskarteringar då det är viktigt med vattenståndsprognoser. För alla skalorna finns krav på lägesnoggrannhet och det är även viktigt med aktualitet och spårbarhet för data. Det finns även GIS-krav, data ska kunna användas i databasmiljöer som t ex ESRI. Sjöar, vattendrag, rinnsträckor mm ska vara enskilda objekt med unika ID:n och namn. Intressant information, som saknas idag, är kartinformation med anknytning till hydrografi, t ex sankmarker och glaciärer samt hydrogeologisk info från SGU. I NSL specifikationen finns möjligheter att i framtiden utöka objekttypskatalogen med bl a vrak, sjöfartshinder, områden och gränser. Eftersom data från olika leverantörer ofta kombineras måste topologiska krav och logisk konsistens uppfyllas och hydrografin ska överensstämma med övriga data. På sikt finns önskemål om nätverksbildad hydrografi i skala 50,000 samt olika nivåer av modellering i samma nätverksmodell. Åtkomst och leveranser Behovet av åtkomst är idag huvudsakligen kontorstid och leveranser via avtal med möjligheter att beställa kompletteringar och data separat. Det finns akuta behov att få ortnamn till sjöar och vattendrag för att kunna komplettera registren. GDB-alfa online åtkomst finns för NSL åtgärder och ortofoton kan fås via webbtjänst. I framtiden finns för alla skalområden önskemål/behov att kunna få leveranser via webbtjänst och med online åtkomst. Förändringsdata/uppdateringar i informationen behövs årligen eller för NSL kontinuerligt då förändringen är ett faktum. Det finns också behov av leveranser efter t ex distrikt, avrinningsområden och ansvarsområden istället för dagens kommunvisa leveranser. Hur leveranser enligt standard där stora datamängder ingår ska hanteras behöver diskuteras och överenskommelser
Intressentsamverkan.doc Bilaga 2 skapas mellan olika aktörer. För felrapportering kan webbformulär och e-post användas, RättaKartan är ett bra exempel på en felrapporteringsfunktion. Metadata Metadata för dataseten ska ge information om kvalitet, aktualitet, historik, version, processmetod och insamlingsmetod/ursprung. För sjöar behövs metadata om höjdvärde och tidpunkt för mätning samt använt höjdsystem. Till objekten är det intressant med bilddata i form av ortobilder samt information om bildens datum, uppdateringsfrekvens och processhistorik. FRAMTIDA KRAV OCH ANVÄNDNING Prioritet 1 för framtiden är ökad kvalitet och aktualitet på befintlig information. För NSL kommer nautisk information i farledsområden och för hamnområden att utökas. För att öka nyttan och effektiviteten hos de samverkande myndigheterna kan LM utöka informationen med strandlinje och areal vid dämnings- och sänkningsgräns för reglerade sjöar. Detta kan kräva samverkan med kraftindustrin. Ortofoton bör förses med metadata om datum, tid och aktuellt vattenstånd vid flygkarteringen. Högupplösta satellitbilder kan bidra till aktuellare information och vara ett komplement eller en ersättning till flygbilder. Det ger en högre aktualitet och bättre tillgång till data. Inga svar huruvida framtida krav från EU kommer att påverka dagens hydrografiska data. SAMVERKAN Samverkan skulle underlättas av införandet av en nationell infrastruktur. LM bör ansvara för insamling av data och geometrier och för att skapa UUID för objekten. SMHI bör dock ha huvudansvaret för indelning i bassänger och för nätverksbildning. SMHI har gjort en del förbättringar i Bas 250 och dessa förbättringar bör återföras till Lantmäteriets databas. Samförstånd måste uppnås om hur denna återföring ska göras. Det finns hos samtliga parter intresse att ha ett gemensamt ajourföringssystem exempel på regler finns i NSL. Lagringsutrymmet bör vara gemensamt och föreslås finnas hos LM, det krävs uppbyggnad av system för att underlätta utbyte av data. Intressenter använder data från ett flertal aktörer och datastruktur bör anpassas utifrån överenskommelser med respektive aktör och det bör finnas möjligheter att få tillgång till varandras data. Sjöfartsverket följer internationella standarder för hydrografisk information men har ej tagit beslut om tidpunkt för införandet av Ytvattenstandarden, SMHI hoppas ha sitt system anpassat till Ytvattenstandarden senast under 2008. HISTORIK Det finns behov av information om ursprung på data, förändringar i data, datum för tillkomst och ändring, mellan vilka datum olika versioner gäller samt spårbarhet av informationsförändringar. Historiska uppgifter bör samlas in då data införs i databaser. Bör finnas historik både om ajourhållning och databashistorik. Metadata för objektet är ett lämpligt sätt att beskriva historik som är specifikt för objekt/objekttyp. Det ska vara obligatoriskt med spårbarhet för alla uppgifter men utredning behövs om vilken tillkomsthistorik som ska finnas. Det är viktigt att processhistorik - vem har gjort vad och hur beskrivs, samt att tidpunkter för dessa förändringar anges. Beskrivning kan bestå av metadata och versionshantering. Versionshantering ska i första hand beskriva ajourhållningsversioner, inte årsversioner. Versionerna ska innehålla kvalitetsmärkning och unika ID:n för objekt för att underlätta inkrementella uppdateringar. Databashistorik behövs för att kunna felsöka och styrka innehåll i databasen vid ett givet tillfälle bakåt i tiden. KVALITET För NSL görs granskning och verifiering av data kontinuerligt. Sjöfartsverkets verksamhet är ISO 9001 certifierad och revisioner görs fortlöpande, data borde kvalitetsmärkas på sikt (5 år). Logiska
Intressentsamverkan.doc Bilaga 3 regler ska kontrolleras vid skapande av data, vid uppdateringar, konverteringar och innan leverans av produkter. Exempel på sådana kontroller är t ex väg får inte gå över byggnad, väg får inte ligga i vatten m fl. Det finns även tillfällen då en vattenyta delats i två sjöar av vägbankar, här måste samråd ske mellan LM/SMHI för att ta fram regler för hur sådant ska behandlas. Kvaliteten i grunddataprodukter bör säkerställas genom kvalitetssäkringsrutiner där upptäckta felaktigheter åtgärdas samtidigt som arbetsrutiner förbättras för att undvika dessa typer av fel. METADATA En gemensam metadatabas är önskvärd. Olika delar av denna ska kunna administreras av olika organisationer. Metadata ska ha bra kvalitet, egna kontroller ska utföras enligt kunders krav på produkter. Användningsområden för metadata är att hitta data, hur få tillgång till data, se vem som är ansvarig för data och att erhålla en sammanfattande beskrivning av aktualitet och kvalitet. Denna information används för att bedöma datats användbarhet, vilket leder till högre kvalitet på data och ökad effektivitet i verksamheter. Metadataregistrering är kostnadskrävande men leder till att rätt data kan användas till rätt uppgift vid rätt tillfälle. Det leder till kostnadsbesparingar hos den allmänna samhällsnyttan och möjliggör analyser, bearbetning, presentation och nytta för flera aktörer.