SpatialData4s

In een organisatie bestaan allerlei redenen (functioneel, technisch, organisatorisch etc) die het noodzaken om met meerdere GIS-tools van dezelfde data gebruik te willen maken. Je kunt dan denken aan aanwezige tool-kennis en ervaring binnen een organisatie of aan de hoeveelheid functionele deelgebieden en manier waarop van spatial-data gebruik wordt gemaakt. 

De architectur van Spatial-Data-Infrastructure bepaalt uiteindelijk de keuze van de in te zetten GIS-tools.  

Het biedt voordelen om GIS-tools in te zetten die rechtstreeks met Oracle*Spatial kunnen werken zonder specifieke beperkingen in opslag en structuur van datamodel, ondersteuning spatial object-types of noodzakelijke metadata. Je kunt dan denken aan:

• object/record mutaties in plaats van optimistic-locking van objecten in een uitgechecked gebied
• presentatiekenmerken (kleur, symbology, etc) centraal te beheren
• realtime spatial*validatie mogelijk
• realtime business-rule-validatie mogelijk
• centrale database-foutafhandeling 
• efficiency in mutatieverwerking, minder handmatige acties/werkzaamheden
• eenmalige opslag en beheer, minder kans op fouten/afhankelijkheden
• altijd de beschikking over meest actuele data
• autorisatie/authenticatie centraal te beheren
• multi-user/tasking 
• automatische generalisatie van objecten die gerelateerd zijn aan gemuteerde objecten

Indien een organisatie gebruik wil maken oracle*spatial-database-functionaliteit zoals:

• database-netwerk-topology
• spatial-analyses

dan is een directe connectie zelfs noodzakelijk.
Ook voor omvangrijke analyses op grote hoeveelheden data blijft een database de meest efficiente plek om dit te doen, zonder eerst alle data uit de database te hoeven halen en deze vervolgens via netwerk naar applicatie-server of client te moeten halen.

Binnen de GIS-tools is verder een onderschied te maken in commerciele en open-source-applicaties. Dit maakt verder voor de structuur van een SDI niet uit. Beide varianten kunnen naast elkaar binnen een SDI worden ingezet.

Zoals uit bovenstaande al blijkt is er geen algemene stelregel hoe zaken te implementeren. De eisen zullen per organisatie verschillend zijn. Het is tegenwoordig vaak niet meer de vraag OF de interfaces tussen database en tooling gemaakt kunnen worden, maar zou meer de vraag op het HOE gericht moeten zijn, en HOE efficient er met de GIS-tools van de gemeenschappelijke spatial-data gebruik gemaakt kan worden. 

Hieronder is een overzicht opgenomenn van tooling die we binnen een SDI tegen kunnen komen. Hierbij zijn de GIS-tools globaal in de volgende functionele deelgebieden onder te verdelen:

• Extract/Transform/Load-tools (ETL)
  Bijv: FME, DgDialog (nen1878, nen3610), Import-S57, 

• Analyse-tools
  Bijv: Arcgis, Genamap, Geomedia
  
  
• Mapserver-tools tbv aanbieden services (WMS/WFS, etc)
  Bijv: Erdas apollo, Geoserver, etc.
  
  
• Edit-tools
  Bijv: Arcgis, Geomedia, Autodesk, etc
  
  
• Viewer-applicaties
  Bijv: ArcView, FME, Xmarc, Geomedia,
  
  
• Web-viewer applicaties
  Bijv: google earth/maps, microsoft virtual earth, java/open-layers, etc.
  
  
• Cartografische-tools
  Bijv: Digisys, Arcgis, etc.
  
  
• 3D-viewers
  Bijv: Autocad, 
  
  
• Operationeel-beheer-tools met specifieke kennis/rekenregels
  Bijv: DgDialog-CROW voor wegenonderhoud, QARTO voor ENC-productie, etc.
  
  
• Database-ontwikkel/beheer tools
  Bijv: SQL*Developer incl. Georaptor, Toad, 
  
  
• Topology
  Bijv: Radius Topology, 
  
  
• Business-Rule-Validation
  Bijv: Radius Studio,