PR O PO S A L F O R A W E B E NC OD I NG S E R V I C E (W E S) F OR S PA T I A L D A T A
T R A NSA C T I O N
C . B . Siew a, S. Peters a, A . A bdul R ahman a a
Geospatial Information Infrastructure, F aculty of Geoi nformation and R eal E state, Universiti T eknologi Malaysia ( UT M) , J ohor B ahru, Malaysia – bernad@ bernadsiew.name, stefanpeters@ utm.my, alias@ utm.my
K E Y W OR D S: E ncoding, W eb service, SD I, D ata T ransaction
A B ST R A C T :
W eb services utilizations in S patial Data Infrastructure (S D I) have been well established and standardized by Open Geospatial C onsortium ( OGC ). Similar web services for 3D SD I are also being established in recent years, with extended capabilities to handle 3D spatial data. T he increasing popularity of using C ity Geographic Markup L anguage (C ityG ML ) for 3D city modelling applications leads to the needs for large spatial data handling for data deli very. T his paper revisits the available web services in OGC W eb Services ( OW S) , and propose the background concepts and requirements for encoding spatial data via W eb E ncoding Service ( W E S). F urthermore, the paper discusses the data flow of the encoder within web service, e.g. possible integration with W eb Processing Service ( W PS) or W eb 3D Services (W 3D S). T he integration with available web service could be extended to other available web services for efficient handling of spatial data, especially 3D spatial data.
1. I NT R O D UC T I ON
C ity models are especially important for presentation of business locations and urban development that is required by public and private sectors, such as providing the platform that supports the process from ci vic participation to decision-making and policy-formulation, as reported by K olbe et al. (2008) . T he usages of C ityGML or GML in S D I architecture especially web services are quite significant due to the verbosity and declarative nature of X ML schema. T hese benefits also come with drawbacks, i.e. when large file size transaction is expected within client to server, or server to server. C onventional compression method coul d solve this challenging task only partially, however, not very well handled. F or instance, a proper compression workflow for a set of data retrieved from a web service is not available. T he approach proposed in OGC best paper (B ruce, 2006) could be used as a generic solution, but a proper spatial data handling service is preferred. T hough currently plain C ityGML or Geography Mark-up L anguage ( GML ) data transaction is being practised across various SD I initiatives, a generalized encoding service could be created for efficient data handling. C ityGML is based on GML which is an X ML standard – a popular W 3C standard in data exchange and sharing usage in computing systems due to its readable and self-describing benefits. However, gi ven the cost involved in storing and transferring the schema over distributed networks, transmitting models in C ityGML format is considered impractical, especially when the city model is used for visualization purposes over the distributed environment. T he use of X 3D for city model representation i n W eb 3D Services (W 3D S) ( S chilling and K olbe, 2010) is then utilized. On the other hand, dealing with semantic data that is required by analysis for orchestration in W eb Processing S ervice ( W PS) , a data model with semantics is necessary. T o deal with these requirements, transmitting C ityGML in large datasets should be well-handled.
E ncoding as a service for spatial data gains binary transaction benefit and maintain interoperability. Such service mi mic the implementation of W PS that could be used for web service chaining. T his service could then be used as an intermediate service specific for spatial encoding. T his web service interface
inherits the OW S standard interface, which allows expandable and customizable encoding capability for spatial data (X ML -schema). Specific encoding scheme could be a step forward towards establishing an application network protocol for efficient and manageable data transaction.
In this paper, Section 2 revisits various OW S and list down its current usages. S ection 3 discusses the concept diagram of the proposed W E S while Section 4 describes the data flow of the W E S in various scenarios. Section 5 then discusses the outlook of the web service and potential integration with other existing web services.
2. B A C K G R O UND
Previous local SD I frameworks are built on web services mainl y from OW S . Galip ( 2007) showcased a SD I framework (F igure 1) for real time data grid utilizing binary X ML as middleware data transaction. T his example showed the requirements for having GIS over distributed environment; compare to existing desktop GIS solutions. In Gong et. al ( 2009) , framework for geospatial information dissemination on the web (see F igure 2) include encoding as a service as a component in data dissemination.
F igure 1. T he SD I framework supporting real time data grid incorporating binary X ML framework ( Galip, 2007) .
F igure 2. Geospatial services components (Gong et. al, 2009).
C urrentl y OW S is being investigated for 3D spatial data include W eb F eature Service ( W F S) ( V retanos, 2010), W eb Processing Service ( W PS ) ( Schut, 2007) and W eb 3D S ervice (W 3D S) (Schilling and K olbe, 2010) . A ll web services are using HT T P protocol. F or W F S, the main usage is facilitating retrieval and updating of geospatial data which is encoded in G eographical Markup L anguage ( G ML ) . T he data delivery is retrieved or updated via GML format. Operation processes such as GetGML Object, or GetF eature is the interface to fetch elements’ instances.
B esides, W PS facilitates geospatial processes and publishing. Processes are defined as any involvement of calculation and algorithms or models that operates on spatial-referenced data while publishing is defined as enabling machine-readable binding information and human-readable metadata for discovery and use. D iscovery and binding of information is done by client. W 3D S, on the other hand, is a service to present 3D portrayal data delivering X 3D as the format for graphical representation. W 3D S offers 3D layer on top of W F S layer for visualization. A s all the web services is compliant to OW S, the generalized interface for service discovery and execution is categorized into 3 main operations: 1) GetC apabilities, 2) D escribeProcess (C ustom Operation) and 3) E xecute.
T he GetC apabilities operation allows client to request and receive service metadata that describe the abilities of the server implementation. It provi des naming and the descriptions of the processes offered by W PS instance. T he operation i mplemented in OW S supports negotiation of the specification version being used for client-server interactions. B esides that, DescribeProcess allows client to request and recei ve back information detail about the processes that could be executed on the service instance. T his includes the required input, permi tted formatting, and the output that will be produced whereas E xecute operation allows client to run a specified process implemented by the web service, by using required input parameters and return the output produced ( S chut, 2007) .
F igure 3. T he W PS operations ( Schut, 2007).
In B inary X M L document (B ruce, 2006) shows how the encoding process could be done for the X ML data. T he approach could be further extended for web service implementation via standard OW S operations. On the contrary, GeoPackage ( D aisey, 2014) from OG C standard discussed on limitation of small devices in terms of storage and network connectivity, and how GeoPackage could improve data dissemination for these environments. GeoPackage emphasises on S QL ite usage and data types for SQL ite D B . T his approach is seen useful in terms of sendi ng the data to client in a package, however, the relationship and workflow with other web services are not discussed.
3. W E S I NT E R F A C E
Si milar to OW S, W E S employs the generalize workflow as depicted in F igure 4.
F igure 4. T he W E S Interface based on OGC .
C onsidering a simple scenario where a request chains this W eb E ncoding S ervice as middleware to obtain encoded data, the response of this web service to a GetC apabilities request indicates that this web service supports the operation of “encodeGML ”, where this operation li mits to encode only one X ML input at an instance. T he response to a DescribeProcess request for the “encodeGML ” process might indicate that it requires one input which is “an X ML ” and this input must be provi ded in G ML 2.2. F urthermore, the process will produce one output, in a Z IP archive that contains several containers with information in it and delivered as a web-accessible resource. T he client would then run the process by calling E xecute operation, and then provide the input of the data embedded directl y within the request (stream) , and identify that the output should be stored as a web-accessible resource.
T he nature of the web encodi ng service is similar to W PS, which is a middleware service. Middleware service obtains data from an external resource in order to run a process on the local implementation. A s a middleware service, it allows current software interfaces to be wrapped up and presented to the
network as web services. T his proposed web service wraps encoding capabilities and the format of the encoding service is based on UT F -8. T his is due to the fact that UT F -8 and UT F -16 are widely accepted in browser-based client.
F or spatial data handling in W E S , for example, binary encoding of X 3D could be implemented as encodeX 3D identifier. Its internal operation depends on the further i mplementation of this W E S in future. C urrentl y, C itySA C (Siew and A bdulR ahman, 2013) could be used in this W E S as the internal encoding engine for encodeGML operation.
4. W E S D A T A F L O W A ND O PE R A T I O NS
In GetC apabilities operation, the request parameters are shown in T able 1. T able 2 shows the response of the service metadata ( X ML ) for discovery purpose. T able 3 shows the request parameters of D escribeProcess operation, while T able 4 shows the response of D escribeProcess operation. On the other hand, T able 5 denotes the E xecute process with its example query over UR L GE T request.
T able 1. T he request parameters in GetC apabilities W E S.
T able 2. T he response of W E S GetC apabilities.
T he response from the GetC apabilities operation will be as shown in T able 2. T he ProcessOfferings refer to the varieties of processes allowed in W E S. T he structure of the ProcessOfferings return will follow ProcessBrief structure. In T able 3, the D escribeProcess sends the request to server to notify the operation that should be executed by providing the operation in the identifier parameter. T he return of the D escribeProcess woul d be the detail of the operation as indicated in the P rocessIdentifier as well as the version of the process as shown in T able 4.
T able 3: T he request of W E S D escribeProcess.
T able 4: T he response of D escribeProcess.
T able 5 shows the request of the operation E xecute and the inputs parameter is mandatory and the output of the execution is also indicated in this request string. In this request, the GE T input generated from W PS or W F S or other web services could be used as input in this stage, then the output of the encoded data could be further defined in the chaining of the web services.
In this case, the identifier of the operation would be “encodeGML ” and this interface will perform encoding with the data return type defined by the RawD ataOutput. W ithin this “encodeGML ”, the encoding is currentl y implementing C itySA C . C itySA C is using dictionary encoding, all occurrences are indexed and stored. F urthermore, geometries are built in chunk of 65,000 face sets where each face represents a polygon in C ityGML . T he main i dea of the encoder is to foll ow the X ML original structure so query-able capability is retained and compressed content is retrievable. T he encoder defines each representation as a symbol denoted in 16-bits. T he encoding fl ow is depicted in F igure 5.
U R L ( G E T request)
Name M ultiplicity C lient Implementation Server Implementation
Serv ice One ( mandatory )
http://foo.bar/foo?service=W E S& R equest=G etC apabilities& A cceptV ersions=0.1.0 & language=en
D escription
Name D efinition D ata ty pe and value M ultiplicity C haracter String ty pe
e.g. “W E S”
L ang L anguage identifier C haracter String ty pe One (mandatory )
ProcessOfferings
L anguages L anguages supported L anguages data structure One (mandatory ) T he response of service metadata
Serv ice Service Identifier One (mandatory )
D escription
E xample
Name D efinition D ata type and value M ultiplicity C haracter S tring type
http://foo.bar/foo?S ervice=W E S& R equest=DescribeProcess& V ersion=0.1. 0& Identifier=encodeGML
service S ervice Identifier One (mandatory)
version V ersion for operation One (mandatory)
D escription
Name D efinition D ata type and valueM ultiplicity
T itle
Inherit from ProcessBrief data structure
C haracter String type One (mandatory)
D ataInputs
C haracter String type One (mandatory)
processV er
T able 5: T he request of E xecute operation.
F igure 5. T he C itySA C encoding workflow in encodeGML operation ( Siew and A bdul R ahman, 2013).
E ncoded data will be decoded by calling on-demand script library in other web services, as the library will decode based on the dictionary built on-the-fl y. T he decodi ng process could be depicted as F igure 6. Note that thi s process is just a reference for decoding a simple 3D spatial object from a scene, queried and encoded by W E S. T he i nput of the decoding process should be the encoded output produced by “encodeG ML ” operation in form of a package/archive.
T he entire web service workflow and usage for encoding spatial data is similar to the intermediary service in the W PS nature. T his encoding as a service concept could then be realized in the chaining of web services in OGC . T he decoding process could be done in client side, or in web servi ces that required further usages on the encoded data. D ecoding process is similar for both, client side for thin client, as well as for thick client due to the code on demand advantage in the decoding requirement.
F igure 6. T he decoding process flow example.
F igure 6 depicts a brief example for decodi ng data at thin client. D ecoding interface is written in browser scripting language, and dictionaries of the encoded data are archived in L Z MA compression scheme. T he decodi ng process starts with a simple SE L E C T of a building, then the getStruct method will obtain the document structure from the archive, by returni ng StructAttribute. Structures are allocated in allocateStruct and the container of the structures will be filled and return to the main operation. T hen, getTreeInfo method will retrieve entire TreeInfo from the archive, therefore parent and child attributes could be used in getC hild method with gi ven UR I. Next, the geometries will be obtained from the archi ve getGeometry and the set of geometry would be retrieved and allocated using allocateGeometry method. Geometry container is now filled with geometries and mapped into the parent and child tree, and then 3D buildings are constructed and returned as F eaturedScene.
5. C O NC L UD I NG R E M A R K S
In this paper we showcase the draft of a new web service called W E S for spatial data compression handli ng. T he proposed W E S is a web service to handle binary compression of spatial data in distributed environment, as its objective is to realise encoding as a service compliant to OW S standards. Initially some OW S are reviewed and discussed in the background section, where the related OW S for binary transaction operations are discussed. W e have shown the nature of W PS as a middleware, which mechanism could be useful for W E S. W e also reviewed B X ML best paper document and discovered the requirements to create a web service specified for compression usage. T he operations of the W E S that is similar to those OW S operations are also demonstrated. E xample of how spatial data is encoded i n the web service operation is also presented, along with the decoding process. T his web service is a step towards a network protocol embeddi ng the binary schema similar to the concept of the W E S.
D escription
E xample
Name D efinition D ata type and valueM ultiplicity C haracter S tring type
V alue is “W E S ” C haracter S tring type V alue is the operation name
e.g. “Execute”
Identifier
Unique identifier for the name of the process
C haracter S tring type. V alue is the process identifier used in C apabilities document
One (mandatory)
D ataInputs
X ML inputs for encoding purposes
GML or C ityGML or X ML compliant documents
One (mandatory)
R awD ataO utput
R aw output return from the web service
R aw data compliant to the mimeT ype
One (mandatory) version
T he specific process version for specific operation
C haracter S tring type, S pecified value indicates the schema version.
One (mandatory) T he Execute operation request parameter
http://foo.bar/foo?request=Execute& service=W E S & version=0.1.0& l anguage=en& Identifier=encodeGML & DataInputs=http%3A %2F %2 F foo.bar%2F foo%2F input.gml& R awDataOutput=EncodedBuildings @ F ormat=application/octet- stream
S ervice S ervice type identifier One (mandatory)
R equest Operation name One (mandatory)
W ith W E S, specific encoding could be employed and used over web service chaining and orchestration. V arious existing or new web service could be easily chained with W E S. T he W E S could be further extended by employing more encodi ng scheme in the P rocessOffering.
A C K NOW L E D G E M E NT S
W e woul d like to convey our deepest acknowledgement to Ministry of Higher E ducation ( MOHE ) , Malaysia for the scholarship under the program MyPhD - M yB rain15 and enabling us to carry out this research project.
R E F E R E NC E S
B ruce C ., 2006, B inary E xtensible Markup L anguage (B X ML ) E ncoding Specification, OGC B est Practices document, OGC ® 03-002r9
D aisey Paul, 2014, OGC ® GeoPackage E ncoding S tandard v1.0, OGC Standard D ocument, OGC 12-128r10
Galip A ydin, 2007, Service Oriented A rchitecture for Geographic Information S ys-tems Supporting R eal T ime Data Grids, PhD D issertation, D epartment of C omputer Science Indiana University
Gong J ianya, Huayi W u, W enxiu Gao, Peng Y ue, X inyan Z hu, 2009, Geospatial Service W eb, G eospatial T echnology for E arth Observation, Springer Science, DOI 10.1007/978-1-4419-0050-0_ 13.
K olbe T . H., Gerhard K ., Nagel C ., Stadler A ., 2008, 3D Geodatabase B erlin ver-sion 2.0.1a, F achgebiet M ethodik der Geoinformationstechnik der T U B erlin
Panagiotis A . V retanos, 2010, OpenG IS W eb F eature Service 2.0 Interface S tandard, OGC Implementation Standard, OGC 09-025r1
Schilling A . K olbe T .H., 2010. D raft for C andidate OpenGIS® W eb 3D Service Interface Standard, V ersion: 0.4.0, OGC 09-104r1 pp. 95.
Schut P., 2007, OpenGIS® W eb Processing Service, OpenG IS Standard, OGC 05-007r7
Siew, C . B ernad, A lias A R ahman, 2013, A schema-aware encoder for Putrajaya 3d, Urban and R egi onal D ata Management, UD MS A nnual 2013 - Proceedings of the Urban Data Management S ociety S ymposium 2013 , pp. 181-190.
