RVF Utveckling. Överföringsformat mellan administrativa system, planeringssystem. uppföljningssystem inom renhållning

Transkript

1 Överföringsformat mellan administrativa system, planeringssystem och uppföljningssystem inom renhållning RVF Utveckling 2002:07 ISSN RVF Utveckling

2 RVF Utveckling 2002:07 ISSN RVF Service AB Tryck: Daleke Grafiska 2002 Upplaga: 1000 ex

3 Förord Genom ett ökat användande av datoriserade rutiner för planering och uppföljning av avfallshanteringen ökar också behovet av samordning vad beträffar kommunikationen mellan olika typer av dataprogram. Framförallt gäller detta hur befintliga administrativa program ska kunna fungera tillsammans med de allt vanligare kart- och ruttplaneringsprogrammen. Fördelen blir att data kan föras mellan olika typer av program med hjälp av enkla gemensamma gränssnitt. Arbetet har utförts dels av Unwire AB, dels av B&M Systemutveckling. Malmö i april 2002 Anders Assarsson Ordf. RVF:s Utvecklingskommitté Weine Wiqvist VD RVF

4 2

5 Överföringsformat mellan administrativa system, planeringssystem och uppföljningssystem inom renhållning 1 Sammanfattning Inom renhållningsverksamheten används idag olika typer av datasystem. Dessa system har olika syften och funktioner för bl.a. följande : Abonnentregister Turplanering Ruttoptimering Uppföljning Statistik Fakturering Eftersom de existerande systemen har olika funktionalitet finns det behov av att kunna utnyttja flera system bland de beställare och entreprenörer som finns i branschen. För att underlätta användningen av flera parallella system är det önskvärt att data mellan systemen enkelt kan utbytas och underhållas. Detta dokument beskriver metoder för utbyte av data mellan system. Metoderna är till för att underlätta detta utbyte och för att skapa en standard för vilken information som ska överföras och hur den ska överföras. Utredningen föreslår att XML används som format för att flytta information. XML är i princip en textfil som innehåller koder (tags) för att göra överföringsformatet strukturerat och flexibelt. XML filer kan läsas t.ex. i Internet Explorer vilket gör att det är relativt enkelt att utveckla system som stödjer detta överföringsformat. Dokumentet innehåller även exempel/förslag på format för överföring, samt praktiska exempel på olika system. 3

6 2 Innehållsförteckning Sammanfattning... 3 Innehållsförteckning... 4 Dokumenthistorik... 5 Bakgrund... 5 Syfte... 6 Avgränsning... 6 Begrepp... 7 Överföringsformat... 8 Kunddata... 8 Hämtningsdata... 8 Geografisk data... 9 Vektordata... 9 Rasterdata... 9 Överföring av vektordata... 9 Innehåll i vektordata... 9 Format på vektordata Data som behövs för ruttberäkningar Bilaga 1.WasteCustomerExport Bilaga 2. Några exempel på hur Kalmar använder GIS inom renhållningen

7 Dokumenthistorik Datum Åtgärd Ansvarig Dokument upprättat Lars Mauritzson Justerat detaljer. Lagt till en Lars Mauritzson del om data som behövs för ruttberäkningar Färdigställning. Lagt till begreppslista. Justerat xml specifikation. Infört praktiska exempel på tillämpningar. Lars Mauritzson 3 Bakgrund Det finns på marknaden idag olika system som används inom renhållningsverksamhet. Systemen kompletterar varandra vad avser funktionalitet och flera system används ofta inom en verksamhet. Ofta förekommer det också att entreprenör och beställare använder olika system då de har olika behov och inriktning. Eftersom det finns olika system som ofta behöver utnyttja samma grunddata är det önskvärt att kunna överföra data mellan systemen. Denna data kan delas in i följande kategorier : Kunddata o avser data om kunder, deras tjänster, hämtställen, behållare etc. Hämtningsdata o vid hämtning kan system samla in information om hämtningen Geografisk data o avser data för system som använder kartor (GIS=Geografiska Informationssystem) En del av denna data kan användas för att göra ruttberäkningar, dvs förslag på vilka behållare som ska hämtas i en viss tur och i vilken ordning det ska göras. 5

8 4 Syfte För att förenkla utbytet mellan olika system och för att göra kunder mindre beroende av olika programsystem är det önskvärt att det finns ett vedertaget sätt att flytta data mellan de olika programmen. Detta kan användas för att flytta data mellan system som har olika funktionalitet, för att därigenom få ett mer komplett system med många olika funktioner. Överföringen kan givetvis också användas för att flytta data mellan system som har samma funktioner, t.ex. om någon kund vill byta system. Dataöverföringen kan även användas vid upphandling för att man ska kunna ge samma underlag till olika anbudsgivare. Kostnaderna för alla parter inom renhållningsverksamheten borde kunna minskas, och även tiden för att få till fungerande system. Dokumentet syftar även till att svara på vilken data som behövs för ruttplanering. Överföring av data mellan systemen är ofta tidskritisk, för att kunna ge kunder snabba besked. Detta ställer krav på hur systemen utbyter data. 5 Avgränsning Dokumentet behandlar inte id-insamling från behållare eller vägning, förutom genom att ange att denna data kan samlas in och överföras. 6

9 6 Begrepp Följande är en enkel förklaring av begrepp som ingår i detta dokument. Begrepp Kunddata Överföringsdata Hämtningsdata Avvikelser GPS Vektordata Rasterdata XML Ruttberäkningar Administrativa system Förklaring Data som innehåller information om abonnemang, tjänster, hämtställen etc. Den data som överförs mellan systemen Information om utförda hämtningar i en renhållningsverksamhet Om en hämtning inte genomförs planenligt System för att göra positionsbestämning Geografisk data som består av ritinstruktioner. Idealisk för att hantera kartor i olika skalor. Geografisk data som består av en inscannad bild. Enkel, men inte så bra i olika skalor Överföringsformat att använda mellan olika system Beräkningar som utförs med hjälp av geografisk data och kunddata för att planera och optimera hämtningar. System som innehåller information om kunder (kunddata). Svarar även ofta för fakturering etc 7

10 7 Överföringsformat Bifogat detta dokument finns ett förslag till ett överföringsformat. Projektgruppen anser att XML (som betyder extensive Markup Language) kan vara ett lämpligt format att använda vid utbyte av data mellan olika system. XML är i princip en utökning av HTML standarden som används för webbsidor. Fördelen med XML är att data överförs i form av strukturerade textfiler som dels är läsbara som en vanlig text, men även lämpade för bearbetning av dataprogram. Strukturen som används i en XML fil underlättar t.ex. för att i överföringsformatet visa vilka relationer som finns mellan olika informationsgrupper. 8 Kunddata Kunddata som överförs mellan systemen består av följande huvudgrupper av information: Kund Tjänster innehåller bl.a. namn, faktureringsadress, telefonnummer. för varje kund finns det en eller flera tjänster. Tjänsterna anger t.ex. vilka typer av sopor som ska hämtas. Hämtställen för varje tjänst kan det finnas en eller flera hämtställen. Ett hämtställe har en adress (kan vara skild från faktureringsadress), ofta en fastighetsbeteckning etc. Behållare Rutter På varje hämtställe finns det en eller flera behållare som också kan innehålla flera fraktioner. Behållarna kan ha en geografisk punkt angivet. Färdiga rutter innehåller information om vilka behållare som hämtas och även när dessa behållare hämtas. Alla system har inte möjlighet eller är inte gjorda för att hantera data i alla dessa grupper. Men det är viktigt att dom ändå kan hantera överföringsdata som är indelat på ovan angivet sätt. Saknas någon typ av information i ett system så kan den givetvis inte konstrueras för att göra en överföring, men systemen ska kunna hantera en överföring som innehåller mer eller mindre data än vad som systemet kan tillgodogöra sig. I de fall informationen inte är strukturerad på ovanstående sätt måste funktioner för överföring anpassas så att data vid överföring likväl är strukturerat enligt ovan. 9 Hämtningsdata Hämtningsdata innehåller information om utförda hämtningar. Detta består av följande : Behållare/fraktion som är hämtad Vem (fordon) som har utfört hämtningen Tidpunkt för hämtningen Eventuella avvikelser vid hämtning Position för hämtning (t.ex. erhållet via GPS). Positionen kan genom att samlas in på detta sätt bilda ett underlag för att spara en position för behållaren (se ovan). Positionen kan även användas för att man ska kunna få ett underlag för vilken väg som rutten går. Vikt Volym Id Tider kopplat till typ av behållare etc. 8

11 10 Geografisk data Vissa system innehåller funktioner för att presentera t.ex. kunddata i en digital karta. Det kan även finnas funktioner för ruttplanering, som ställer särskilda krav på den geografiska datan. Geografisk data kan delas in i två huvudgrupper : 10.1 Vektordata Geodata som är vektoriserad kan presenteras i många olika skalintervall eftersom detta format innehåller ritinstruktioner för de olika objekten i kartan. I regel är datan även indelad i olika skikt, där varje skikt innehåller en viss typ av information (t.ex. vägar, markytor etc). Vektordata är att föredra om man vill koppla extra information till kartan (information som inte finns i kartan från början) Rasterdata Rasterdata är en bild som t.ex. kan vara inscannad från en vanlig papperskarta. I regel är denna information inte indelad i olika skikt, vilket innebär att presentationen inte är lika flexibel som vid användning av vektordata. I regel är det billigare med rasterdata, och det kan även vara enklare i vissa fall att plocka fram denna typ (skapa ny) av geodata. Vektordata och rasterdata kan användas tillsammans. 11 Överföring av vektordata Vektordata kan lagras på en mängd olika format. Nästan samtliga GIS system (program) på marknaden har ett eget format. En del av programmen har funktioner för att exportera eller importera data mellan vissa format. Ofta måste vektordata kompletteras med inställningsfiler som anger hur olika typer av objekt ska ritas, t.ex. vilka färger som ska användas. Det är inte många system som klarar av att även exportera eller importera dessa inställningar Innehåll i vektordata Vektordata som överförs bör ha följande egenskaper : Bilda en lämplig bakgrunda att arbeta mot. Användaren ska känna igen sig i kartan, som måste innehålla information som t.ex. svarar mot en normal stadskarta. Innehålla information om fastigheter och/eller byggnader. Denna del av informationen kan t.ex. användas för att plocka fram vilka geografiska punkter som behållaren befinner sig på. Oftast kan man inte på detta sätt ange exakt var inom en fastighet som behållarna finns, men det räcker ofta som ett startvärde eller som en approximation. För att kunna göra ruttberäkningar krävs vägdata som består av ett länk-nod nät. Denna data kan även innehålla information om hastigheter, enkelriktade vägar, svängrestriktioner etc. Tillgången på vägdata som är länk-nod bildad är ofta dålig eller begränsad. Det krävs även att denna data uppdateras relativt ofta för att den ska vara lämplig att använda för dessa beräkningar. 9

12 11.2 Format på vektordata Beroende på vem som levererar geodata kan leverans ske i olika format. Man bör sträva efter att den som producerar data även levererar det direkt i det format som ska användas av det aktuella systemet. Konvertering mellan olika format ska göras så nära källan som möjligt. Med detta synsätt är det inte lämpligt att definiera ett specifikt överföringsformat, utan det viktiga är innehållet i den data som systemen ska använda. Innehållet styrs till viss del av vilka funktioner som finns i det aktuella systemet, men leverantören av geodata bör kunna leverera data med ovanstående innehåll i det format som efterfrågas av det aktuella systemet. De GIS system som använder ett format som inte är känt av större dataleverantörer har i regel egna funktioner för att konvertera data i ett känt format till sitt eget format. Följande format på vektordata är idag vanligt förekommande (exempel!) : Shape (från ESRI, används t.ex. av ArcView) MapInfo (från MapInfo, används t.ex. av MapX) DGN DXF 12 Data som behövs för ruttberäkningar Ruttberäkningar ställer krav på följande data : Geografisk data : Vägdata. Vägdatan bör vara organiserad i en länk-nod orienterad databas för att beräkningar ska kunna utföras. Kunddata : Information om var de olika behållarna är placerade. Denna placering kan erhållas via administrativa system, eller genom att matcha fastighetsbeteckningar och/eller adresser. Genom att utnyttja GPS utrustning kan dessa positioner också läsas in automatiskt. Information om hur ofta de olika behållarna ska tömmas. Innehåll i behållarna. 10

13 Bilaga 1 - WasteCustomerExport Revisionshistorik Version Release Ansvar Revisionsnotiser datum LM Första utkast LM Kompletterat. DOKUMENTATION Dokumentationen består av Detta dokument DTD-filen WasteCustomerExport.dtd En huvudexempelfil kallad WasteCustomerExport.xml. Dess exempeldata motsvarar de exempeldata som finns i elementtabellen nedan. 11

14 Inledning Detta dokument utgör specifikation för det xml format som är definierat för överföring av kunddata mellan system som används inom renhållningsbranschen. Följande delar beskrivs i detta dokument : Element anger vilka fält som ingår i överföringen DTD-fil är en beskrivning av den struktur som kan gälla i överföringen Exempelfil visar hur det kan se ut med verklig data Observera att detta dokument är ett exempel på hur överföringsformatet kan se ut. Olika system har olika information, därför kan formatet och dess innehåll se olika ut i olika fall. 12

15 Element Följande delar ingår i Elementbeskrivningen : Tabellerna består av följande kolumner: Elementnamn/Attributnamn En unik identifikation för varje element/attribut Status/förekomst Beskriver om elementet är obligatoriskt (REQUIRED) eller valfritt (IMPLIED). Max längd Beskrivs med antal tecken. Vid numeriska fält med decimaler avser antalet hela fältets längd med heltal, decimalskiljetecken och decimaler. Datatyp, möjliga typer är Alfanumerisk AN ABCDEFGH-!?\. Numerisk NUM 234 Nollutfyllt numeriskt 0NUM Datum DATE YYYYMMDD Tid TIME HHMMSS Decimaler Beskrivs med antal decimaler (vid NUM och 0NUM). Decimalskiljetecken är punkt (.). Värde/exempeldata Exempeldata är omgivna av citationstecken. Fasta (fixa) värden är utskrivna med fet text. Dessa värden skall alltid läggas in. Kommentar beskrivning av elementets användning. 13

16 ELEMENT Följande element ingår i meddelandet. Elementnamn Status Längd Datatyp Decimaler Värde/Exempel Kommentar DocumentIssueDate REQUIRED 8 DATE Datum för dokumentets framställande DocumentIssueTime REQUIRED 6 TIME Tidpunkt för dokumentets fram-ställande. CustomerId IMPLIED 15 AN AB9876 Kundid CustomerFirstName IMPLIED 20 AN Lars Förnamn CustomerLastName IMPLIED 20 AN Svensson Efternamn CustomerAddress IMPLIED 40 AN Götg 10 Kundens faktadress CustomerZipCode IMPLIED 10 AN Postnr CustomerCity IMPLIED 20 AN Göteborg Ort CustomerPhone IMPLIED 15 AN Telefon CustomerComment IMPLIED 50 AN Glad kund Kommentar om kunden SiteId REQUIRED 20 AN Q76 Anläggningsid PickupId REQUIRED 20 AN Q76_01 HämtställeId PickupAddress IMPLIED 40 AN Götg 11 Hämtställeadress PickupEW IMPLIED 20 AN Koord i öst/västlig riktning PickupNS IMPLIED 20 AN Koord i nord/syd riktning PickupDistance IMPLIED 10 NUM 12 Meter gångväg PickupNrOfContainers IMPLIED 10 NUM 11 Antal behållare PickupTaxa IMPLIED 20 AN ZS 87 Taxa för hämtstället ContainerId IMPLIED 20 AN ss456 Id på behållare ContainerType IMPLIED 20 AN K190 Typ av behållare ContainerTransponderId IMPLIED 20 AN fd456 TransponderId på behållare TripId IMPLIED 20 AN D56 Id på tur TripName IMPLIED 20 AN Grön 67 Namn på tur TripWeek IMPLIED 2 NUM 4 Veckokod TripDay IMPLIED 2 NUM 3 Dagkod PickupOrder IMPLIED 6 NUM Turordning inom tur 14

17 DTD fil <?xml version="1.0" encoding="iso "?> <!-- edited with XML Spy v3.5 NT ( by Lars Mauritzson (B&M Systemutveckling AB) --> <!ELEMENT WasteCustomerExport (MessageInformation, Customer+)> <!ELEMENT DocumentIdentification (DocumentIssueDate, DocumentIssueTime)> <!ELEMENT DocumentIssueDate (#PCDATA)> <!ELEMENT DocumentIssueTime (#PCDATA)> <!ELEMENT MessageInformation (DocumentIssueDate, DocumentIssueTime)> <!ELEMENT Customer (CustomerId, CustomerFirstName, CustomerLastName, CustomerAddress, CustomerZipCode, CustomerPhone, CustomerComment, CustomerCity, Pickup+)> <!ELEMENT CustomerId (#PCDATA)> <!ELEMENT CustomerFirstName (#PCDATA)> <!ELEMENT CustomerLastName (#PCDATA)> <!ELEMENT CustomerAddress (#PCDATA)> <!ELEMENT CustomerZipCode (#PCDATA)> <!ELEMENT CustomerPhone (#PCDATA)> <!ELEMENT CustomerComment (#PCDATA)> <!ELEMENT CustomerCity (#PCDATA)> <!ELEMENT SiteId (#PCDATA)> <!ELEMENT Pickup (PickupId, PickupAddress, PickupEW, PickupNS, PickupDistance, PickupNrOfContainers, PickupTaxa, Container+)> <!ELEMENT PickupId (#PCDATA)> <!ELEMENT PickupAddress (#PCDATA)> <!ELEMENT PickupEW (#PCDATA)> <!ELEMENT PickupNS (#PCDATA)> <!ELEMENT PickupDistance (#PCDATA)> <!ELEMENT PickupNrOfContainers (#PCDATA)> <!ELEMENT PickupTaxa (#PCDATA)> <!ELEMENT ContainerId (#PCDATA)> <!ELEMENT ContainerType (#PCDATA)> <!ELEMENT ContainerTransponderId (#PCDATA)> <!ELEMENT TripId (#PCDATA)> <!ELEMENT TripName (#PCDATA)> <!ELEMENT TripWeek (#PCDATA)> <!ELEMENT TripDay (#PCDATA)> <!ELEMENT PickupOrder (#PCDATA)> <!ELEMENT Container (ContainerId, ContainerType, ContainerTransponderId)+> 15

18 Exempelfil <?xml version="1.0" encoding="iso "?> <!-- edited with XML Spy v3.5 NT ( by Lars Mauritzson (B&M Systemutveckling AB) --> <!DOCTYPE WasteCustomerExport SYSTEM "WasteCustomerExport.dtd"> <WasteCustomerExport> <MessageInformation> <DocumentIssueDate/> <DocumentIssueTime/> </MessageInformation> <Customer> <CustomerId>AB9876</CustomerId> <CustomerFirstName>Lars</CustomerFirstName> <CustomerLastName>Svensson</CustomerLastName> <CustomerAddress>Götg 10</CustomerAddress> <CustomerZipCode>123 45</CustomerZipCode> <CustomerPhone>111 22</CustomerPhone> <CustomerComment>Glad kund</customercomment> <CustomerCity>Göteborg</CustomerCity> <Pickup> <PickupId>Q76_01</PickupId> <PickupAddress>Götg 11</PickupAddress> <PickupEW>676767</PickupEW> <PickupNS>19191</PickupNS> <PickupDistance>12</PickupDistance> <PickupNrOfContainers>11</PickupNrOfContainers> <PickupTaxa>ZS 87</PickupTaxa> <Container> <ContainerId>ss456</ContainerId> <ContainerType>K190</ContainerType> <ContainerTransponderId>fd456</ContainerTransponderId> </Container> </Pickup> </Customer> </WasteCustomerExport> 16

19 Bilaga 2 - Några exempel på hur Kalmar använder GIS inom renhållningen. Kartan består bla annat av Som linjer eller ytor Fastighetsindelning Byggnader Vägar Som punkter Adresser Fastighetsägare Vald information som importerats från renhållningssystemet Visa information från renhållningssystemet Välj 1, 2, 3, alla poster. För att kunna visas på kartan måste varje post ha X- oxh Y- koordinater. Sök ut aktuella poster och exportera dessa som en fil. I ArcWiew läggs filen till som ett eget tema. För att inte få nya teman varje gång kan man välja att ersätta en befintlig fil, detta är lämpligt om man ska visa tillfällig information. Vid omdimensioneringar kan det vara lämpligt att kunna visa alla poster. 17

20 Att hitta rätt Missad sophämtning Utsättning av kärl Uthyrning av container Vem är fastighetsägare Var ligger fastigheten Vilken adress har fastigheten Bilden visar var den i tabellen markerade fastigheten Förlösa 1:4 är belägen. 18

21 Planering av körturer Vilka har latrinhämtning Hur många trädgårdsavfallskärl finns det i denna delen av kommunen Var finns de som har hämtning två gånger per vecka Var finns de som har sommarhämtning Hur många är det Vilken kärlstorlek är det Bilden visar vilka som har trädgårdsavfall. På kartan har ett område valts ut, dessa är markerade med gult och i tabellen kan man se vilka det är och hur många (189 st). 19

22 Körlista Vilka har hämtning av latrin Visa olika färg beroende på hämtningsintervall Vilka ska hämtas inne på tomten vid hämtning med sidlastare Bilden visar vilka som har latrinhämtning i ett sommarstugeområde 20

23 Bilden visar olika behållarstorlekar och hur många det är av varje storlek på ett sophämtningsdistrikt som kör i glesbygd med fritidshusområden. 21

24 Slamtömning Vi har gjort en applikation i Arc View som skapar en arbetsorder med en kartdel och en del med uppgifter om namn, adress, brunnsstorlek, senaste tömning, anmärkning mm. Ta fram vilken anläggning det gäller, välj lämplig skala. Skriv ut arbetsorder som visar information om anläggningen och var brunnen är belägen. 22

25

26 Rapporter från RVF :01 Hantering av rökgasreningsrest (RGR) från avfallsförbränning (RVF-rapport) 2002:02 Kapacitet för att ta hand om brännbart och organiskt avfall (RVF-rapport) 2002:03 Import av avfall (RVF-rapport 2002:04 Emissioner över deponier. Etapp 1 - Litteraturstudie 2002:05 Karbonatstabilisering av flygaska från avfallsförbränning 2002:06 Jämförelser mellan system för insamling av biologiskt hushållsavfall 2002:07 Överföringsformat mellan administrativa system, planeringssystem och uppföljningssystem inom renhållning RVF - Svenska Renhållningsverksföreningen och RVF Service AB. Prostgatan 2, Malmö. Tel Fax Hemsida E-post office@rvf.se