gbuehler / 6 Goto Github PK

Posted by: on 2010-02-25 10:43:57
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: The current set of thematic classes representing the boundary surfaces of buildings has to be extended in order to be able to semantically classify the entire exterior shell of a building. For example, the floor surface of a loggia/balcony can neither be modeled as bldg:GroundSurface (which may only be used for the ground plate of the building) nor as bldg:FloorSurface (restricted to floor surfaces of interior rooms in LOD4). Further additional boundary surface types are required.

Posted by: on 2009-12-04 08:07:50
Document Title: Web Processing Service Version: 1.0.0
Proposal: Currently each WPS application profile is a standalone document defining a particular process. Each process offering from a WPS may then reference a profile. However, in practice, there may be many processes which are both semantically related and share a common set of input/output parameters (e.g. interpolation from a point dataset to a coverage, which may be implemented using many algorithms). Additionally, an implementer may wish to offer additional (optional) options to those defined in the Application Profile (e.g. extra input/output data types, additional input parameters cf. vendor-specific parameters for other OGC services, etc.). The process should in the latter case still be able to be called in the same way as one which implements exactly the profile.

Posted by: on 2009-12-06 03:53:06
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS spec is lacking support to indicate:

• supported SRS for input/output data
• specification that inputs have to have the same SRS
• specification that outputs will have the same SRS as inputs

Posted by: on 2009-12-04 03:23:33
Document Title: Geography Markup Language (GML) Encoding Standard Version: 3.2.1
Proposal: In GML 3.2.1 the simple type gml:TimePositionUnion is a union of XML Schema simple types which instantiate the subtypes for temporal position described in ISO 19108. These are:

Calendar and clock forms that support the representation of time in systems based on years, months, days, hours, minutes and seconds, in a notation following ISO 8601, are assembled as follows:

ISO 8601:2004 Clause 4.1.2 specifies the Calendar Date and its representations with reduced accuracy (i.e., YYYY-MM and YYYY). gml:CalDate is designed to support their encoding.

ISO 8601:2004 Clause 4.1.3 specifies the Ordinal Date, which is composed from the calendar year and the calendar day of the year (YYYY-DDD).

ISO 8601:2004 Clause 4.1.4 specifies the Week Date, which is composed from the calendar year, the calendar week and the calendar day of the week (YYYY-Www-D). Clause 4.1.4.3 specifies a Week Date representation with reduced accuracy that omits the day of the week component (YYYY-Www).

The ISO 8601:2004 Ordinal Date and Week Date with reduced accuracy are commonly used in certain communities (for example, aviation) but are not currently supported by gml:TimePositionUnion. It is valuable to enhance gml:TimePositionUnion to accommodate representations of these sibling date-representations from ISO 8601:2004.

Posted by: on 2010-02-05 09:30:20
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS does not support processes with an arbitrary number of a certain Input parameter with the same Identifier (for example a list of references or IDs where the number of entries is arbitrary). At the moment, the developer has to specify an upper limit (maxOccurs) for every Input in the process description (see Table 19 - parts of InputDescription data structure, maxOccurs)

Posted by: on 2010-02-25 10:53:18
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: As with any plain-text XML encoding of any content, CityGML instance documents quickly grow in file size . This makes CityGML files slow to transfer over the Internet and the storage of CityGML documents costly. Since XML generally compresses well, file compression can be used to considerably reduce file size and speed up file distribution. Well-known file compression methods such as GZIP are available for this purpose. Furthermore, the OGC has proposed a binary XML encoding format (Binary Extensible Markup Language (BXML) Encoding Specification, OGC Best Practices Doc. No. 03-002r9) which not only addresses space reduction but also scanning-costs as well as costs for the conversion of text-encoded numerical coordinate and observation values.

However, CityGML instance documents often contain references to other files (local or remote) such as additional (City)GML content documents, texture images, or prototypical library objects referenced by core:ImplicitGeometry in any proprietray format (e.g., VRML, X3D, DXF, 3ds, etc.). What is needed in addition to file compression is a compression archive format for CityGML documents and their related files. The format shall define a standardized way how to handle CityGML archives, on which applications can rely. For example, the format should include a fixed content structure (e.g., a single root CityGML document and a fixed subfolder structure for different types of related files), and define allowed compression methods such as legacy ZIP as well as MIME types and file extensions. The archive format of OGC KML (i.e., KMZ) may serve as example.

Posted by: on 2009-12-06 03:58:13
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS is lacking support for allwoing fine grained specification of raster input, such as 2 banded 32 unsigned int raster in geotiff format

Posted by: on 2009-12-04 08:31:58
Document Title: Web Processing Service Version: 1.0.0
Proposal: In WPS 1.0.0 the format of complex inputs/outputs to processes was specified using a tuple of (mimeType, encoding, schema).

This allows only a very broad specification of the data format, and it is not possible for a client to correctly provide data using only this information, e.g.:

• for an XML input it may be necessary to provide a specific root element. This cannot be specified.
• for an XML input it may be necessary to provide a specific structure under the root element (e.g. a gml:FeatureCollection containing elements from a particular application schema, or features having a particular class of geometry attribute such as surface). This cannot be specified.
• for a coverage input it may be necessary to provide a certain number of bands.
• official mime types are not available for all geographic data types (e.g. GeoTIFF is not fully described by image/tiff).

Identification of the correct format was only possible through manually inspecting the natural-language description (abstract) of the input/output.

Additionally, for each input/output it is necessary to repeat the data type definition - e.g. for a process accepting 3 inputs and one output, all with an identical format, the same list of accepted and default formats must be given in total 4 times.

Posted by: on 2009-11-18 10:03:53
Document Title: Web Processing Service Version: 1.0.0
Proposal: The corrigendum corrects and clarifies the contents of the Web Processing Service 1.0.0 Standard. Corrections apply to the explanatory text and examples and do not affect the structure or syntax of the schemas.

Posted by: on 2009-07-14 16:33:48
Document Title: Web Processing Service Version: 1.0.0
Proposal: Improve the ability of client software to present meaningful choices of input/output formats to users.

Posted by: on 2009-06-25 15:41:40
Document Title: Web Processing Service Version: 1.0.0
Proposal: Currently the WPS specification defines two ways to describe inputs and outputs. The first way is via a simple set of OWS Common parameter objects and the second is via XML schema. WPS needs to adpapt better to other data models used in OGC. In particular it would be useful to use the SWE data models to define WPS inputs and outputs so that it can be easily connected to SWE services such as SOS, SPS and the future SAS/SES. When WPS is used to process coverage data, it would be useful that the input/output descriptors align with existing coverage metadata standards.

Posted by: on 2010-02-08 10:28:25
Document Title: Geography Markup Language (GML) Encoding Standard Version: 3.2.1
Proposal: Add mask type value: UNUSABLE.

Posted by: on 2010-02-25 10:45:48
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: Man-made subsurface structures such as tunnels, pedestrian subways, underground stations or subsurface buildings are essential urban objects which have to be adequately represented in virtual 3D city and landscape models. However, CityGML 1.0 does not provide a semantic model explictily dedicated to man-made subsurface structures. The only possibility to model and exchange subsurface objects in CityGML 1.0 is to use a GenericCityObject as proxy. Alternatively, a corresponding ADE could be defined. Both approaches face disadvantages. First, GenericCityObjects are simple in structure and are hence not suitable to replace a semantically rich model for underground objects. Second, subsurface structures are not specific to just a single application domain. Several ADEs could emerge proposing different semantic models. What is required is a common and standardized thematic module on man-made subsurface structures in CityGML.

The Special Interest Group 3D (SIG 3D, initiator of CityGML) of the national Spatial Data Infrastructure of Germany (GDI.DE) has developed a comprehensive data model for subsurface structures. It comprises a rich semantic model for underground objects such as tunnels as well as their geometric representation in four different LODs. The model is based on the CityGML 1.0 Core module and is realized as CityGML ADE. By this means, compliance to the CityGML standard is ensured and existing concepts of CityGML (e.g., appearance modelling, grouping of objects, generic extensions) can be directly applied to the subsurface features.

Posted by: on 2010-01-21 10:58:27
Document Title: Sensor Observation Service Version: 1.0.0
Proposal: There is expressed need for operation-level security based on roles. For example, an SOS may wish to allow a particular user to request one operation but not a different operation, while other users could request both.

Posted by: on 2009-03-17 18:48:43
Document Title: Web Map Service (WMS) Implementation Specification Version: 1.3.0
Proposal: There will be widespread confusion regarding how the server should interpret requests involving an interval dimension value and whether the resolution should be included in the interval or not.

Posted by: on 2010-01-05 13:31:02
Document Title: Web Processing Service Version: 1.0.0
Proposal: not a complete sentence.

Posted by: on 2009-12-18 06:07:06
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: improve the utilisation of existing 2D datasets (topographic building footprints) in the creation of 3D city models. This will allow models to include 2D data that can be rendered in 3D where feature height information does not exist.

Posted by: on 2009-06-25 15:44:54
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS currently defines a particular way to describe inputs, outputs, and description of the process supported by a particular WPS. SensorML is a standard means for defining Processes including properties such as inputs, outputs, method, as well as a host of potentially relevant metadata including characteristics, intended application, security constraints, etc. In addition, SensorML utilizes SWE COmmon which provide a robust means of defining datatypes, including semantics, uom, constraints, etc. In the emerging V2.0 of SWE Common, it also supports choices between input and output messages (i.e it could support options for different inputs).

In addition to providing a good means of defining inputs and outputs, being able to receive WPS definitions as SensorML would greatly ease the inclusion of WPS instances within SensorML process chains for support in processing sensor data.

Posted by: on 2010-01-29 11:05:59
Document Title: CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW Version: 1.0.1
Proposal: According to 06-131r6_EO_Products_Extension_Package_for_ebRIM_(v0.2.5), slot types range definitions are missing from CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW [OGC 07-110r4]. They should be defined in order to map EP concepts to the ebRIM structure, i.e. to define the range of slot types used in the EP

Posted by: on 2010-02-26 08:27:36
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: It is necessary for indoor routing, facility management, floor planning, and so on.

Posted by: on 2009-05-14 10:59:43
Document Title: Web Feature Service (WFS) Implementation Specification Version: 1.1.0
Proposal: GetFeature requests, which use typeNames in the Query element, that are correct according to the specification (i.e. containing underscores or making use of aliases), currently do not validate, if the implementation (i.e. GeoServer in strict cite-conformance mode) uses schema validation to verify the request.

Posted by: on 2009-11-24 06:13:57
Document Title: Web Processing Service Version: 1.0.0
Proposal: When there is a need of describing the processes and its parameters in different languages, it is not possible to do it using more than one ABASTRACT each with its xml:lang="xx" attribute.

Posted by: on 2010-02-25 10:54:24
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: The semantic data model of CityGML 1.0 lacks a model for the representation of walls in cities. However, walls are essential features of cities and it should be possible to adequately represent them in virtual 3D city and landscape models. "City wall" should be broadly defined to not only comprise ancient fortifications, but also smaller walls such as garden walls or fences. As for CityGML 1.0, the only possibility to model and exchange walls in cities is to use a GenericCityObject as proxy or to define a corresponding ADE. Both approaches face disadvantages.

First, GenericCityObjects are simple in structure. However, the representation of city walls requires a semantically rich model. Comparable to buildings, walls can be decomposed into individual parts. Each part may contain interior structures such as rooms, interior installations like pipes, or room furniture. The boundary surfaces of city walls can be further classified as, for example, wall or roof surfaces. Outdoor built structures such as staircases or balconies might be attached to the city wall. Further thematic classes are needed, for example, to represent gates or towers. Second, city walls are not specific to just a single application domain. Several ADEs could emerge proposing different semantic models. What is required is a common and standardized thematic module on city walls in CityGML.

Posted by: on 2009-12-06 19:56:53
Document Title: Sensor Model Language (SensorML) Version: 1.0.0
Proposal: The GeoSciML design group is considering using swe:Quantity to handle numeric values, and request an explicit attribute to describe the statistical type (eg, mean, median) of the quantity value. There are other options for denoting statistical types (eg: using the definition attribute, or xlink:role) but these are not attributes which explicitly denote statistical type.

Posted by: on 2010-02-25 10:46:47
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: Generic attributes as simple means for extending CityGML are very helpful to store additional, native information in CityGML objects, or to easily transport additional data to customers without the need for explicitly defining an ADE (which are not necessarily supported by CityGML-enabled software). Thus, all _CityObject-derived classes provide this capability. The major Appearance model classes are not derived from _CityObject but nevertheless should provide this convenient mechanism.

Posted by: on 2010-02-09 08:36:05
Document Title: SensorML Encoding Standard v 1.0 Schema Corregendum 1 Version: 1.01
Proposal: The ArrayLink in SensorML has some issues. It is insufficient for connecting/linking arrays. More documentation is required.

Posted by: on 2009-11-30 07:01:16
Document Title: Web Map Service (WMS) Implementation Specification Version: 1.3.0
Proposal: The OGC Web Map Service (WMS) specification states that all data layers in the view must have the same projection and datum. However, in order to achieve this some of the data may have needed prior transformation (conversion from one Coordinate Reference System and projection to another) . The issue is that the WMS specification does not currently allow the service creator to record that a transformation has taken place or how it was done.

Posted by: on 2009-06-18 04:59:11
Document Title: Sensor Observation Service Version: 1.0.0
Proposal: Filters specified in a GetObservation request are scattered all around since temporal filters are included in the sos:eventTime tag, Id and spatial filters are included in the sos:featureOfInterest tag, and scalar filters are included in the sos:result tag. This makes the understanding and implementation of such requests very complicated.

Posted by: on 2010-02-25 10:55:56
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: Generic attributes allow for augmenting exisiting CityGML features by application-specific extra attributes in a simple and straightforward way, without the need for explicitly defining an ADE (which are not necessarily supported by CityGML-enabled software). In CityGML 1.0, generic attributes are implemented as simple Name-Value-Pairs with a predefined set of supported data types (gen:intAttribute, gen:doubleAttribute, gen:stringAttribute, gen:dateAttribute, gen:uriAttribute). This definition could be enhanced in two possible ways:

1. In order to correctly interpret and process a generic attribute, not only its value but also the unit of measurement (if applicable) is required. At the moment, it is not possible to give the unit of measurement for generic attributes. This could be simply fixed by adding an attribute "uom" of type "xs:anyURI" (in accordance with GML3.1.1) on the element declaration of the generic attributes.

2. Generic attributes can only be attached to a CityGML feature as unsorted list of single attributes. It is not possible to group a set of generic attributes under a common theme or name. However, this would allow for exchanging "property sets" instead of isolated attributes. This could be simply realized by a named container for generic attributes (e.g., complex type containing an unbounded sequence of _gen:genericAttribute elements). The CityGML standard should neither define concrete property sets nor their content. In contrast, this should be left to user/implementer agreements.

It is well-understood by the authors, that CityGML 1.0 explicitly supports the definition of application-specific property sets by means of Application Domain Extensions. "Generic property sets" would allow to group generic attributes without the need for defining such an ADE - however, at the cost of having a formal definition for the property set in an extra XML schema which helps to maintain semantic and syntactic interoperability. The authors would like to initiate a discussion about generic property sets.

Posted by: on 2010-02-25 10:58:17
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: The position of a CityObject regarding the surrounding terrain or water is important for varies application. If a terrain model is missing in the 3D city model, this position cannot be determined. If a terrain model is available though, this position can still not clearly be defined due to different geometric representations of the terrain in different level of details.

Posted by: on 2009-06-18 04:52:51
Document Title: Sensor Observation Service Version: 1.0.0
Proposal: The SOS specification states that zero or many temporal filters (eventTime tags) may be specified in a GetObservation request. There is no mechanism for a SOS client to know the number of filters supported for a specific server. As a result a client might send a correct request containing more filters than supported by the server, without any warranties about what the server will response. It usually raises an exception.

Posted by: on 2010-02-26 15:50:25
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: There is an overlap between some themes in CityGML and the data themes identified by Inspire annexes, such as transportation networks, land use, terrain models or buildings. The differences to existing Inspire data specifications should be analysed. Proposals for harmonisations or practical reasons against harmonisations need to be documented and fed into the revision process.

Posted by: on 2009-09-01 09:31:54
Document Title: Web Processing Service Version: 1.0.0
Proposal: Facilitate inter-service communication between WPS and OGC Services like WCS or WFS that provide geodata for further processing.

Posted by: on 2010-02-25 10:51:32
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: The semantic model of CityGML 1.0 covers many urban and regional features relevant to 3D city and landscape models. However, it lacks a data model for bridges. The only possibility to model and exchange bridges in CityGML 1.0 is to use a GenericCityObject as proxy. Alternatively, a corresponding ADE could be defined. Both approaches face disadvantages. First, GenericCityObjects are simple in structure and are hence not suitable to replace a semantically rich model for bridges. Second, bridges are not specific to just a single application domain. Several ADEs could emerge proposing different semantic models. What is required is a common and standardized thematic module on bridges in CityGML.

The Special Interest Group 3D (SIG 3D, initiator of CityGML) of the national Spatial Data Infrastructure of Germany (GDI.DE) has recently developed and published a semantic bridge model. It defines the most relevant thematic feature classes for the representation of bridges, comprises generalization and aggregation hierarchies between these features, and provides geometric representations of bridges in four levels of detail, following the LOD concept in CityGML. The bridge model is based on the CityGML 1.0 Core module and is realized as CityGML ADE. Thus, it is fully compliant with the CityGML standard and coherently fits into the overall concept of CityGML.

Posted by: on 2010-02-25 10:41:02
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: The current definitions of the feature class bldg:_BoundarySurface and its child classes do not provide a common set of standard properties for boundary surfaces such as "fire rating" or "load bearing" which are feasible in more than one application domain. As for CityGML 1.0, these common properties can only be modeled and exchanged as generic attributes or using the CityGML ADE mechanism.

Posted by: on 2010-02-26 08:29:46
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: It is necessary for indoor routing, facility management, floor planning, CG visualization, and so on.

Posted by: on 2009-12-06 03:55:37
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS spec is lacking support for associating multiple files to one input such as shp files

Posted by: on 2010-01-29 10:52:58
Document Title: CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW Version: 1.0.1
Proposal: GetCapabilities response element is mandated to "Capabilities" in the "http://www.opengis.net/cat/wrs/1.0" namespace.

This is in contrast with the baseline specification, where the namespace is set to "http://www.opengis.net/cat/csw/2.0.2".

Clients unaware/unsupportive of the ebRIM AP cannot handle the response type

Posted by: on 2009-11-23 06:50:09
Document Title: Web Processing Service Version: 1.0.0
Proposal: Currently the distinction between a WPS Process Description, a WPS Application Profile and a profile of the WPS spec. is not made sufficiently clear: section 6.4 "WPS Profiles" starts by talking about "standardized profiles" and then moves into "Application Profiles".

Posted by: on 2010-01-18 04:59:22
Document Title: ISO Metadata Application Profile Version: 1.0.0
Proposal: The ISO Profile for CSW is the only normative publication of an XML Schema for ISO 19119, so the schema documents published at http://schemas.opengis.net/iso/19139/20060504/srv/ are the only normative ones available. There are a number of problems with this schema, including:

1. the XML namespace used is http://www.isotc211.org/2005/srv - this was never authorized by the owners of the http://www.isotc211.org domain;
2. the schema s the gco and gmd namespaces via a local copy of an interim version of the ISO 19139 implementation of the ISO 19115 metadata schema. In turn this s GML using a local copy of an interim version of GML, which was never formally published. The XML namespace used for the GML components is the one used for all versions of GML up to GML 3.1, but the schema documents are close to what was eventually published as GML 3.2.1. This complicates its use in combination with other GML-based schemas in applications that correctly use official releases of GML.

Posted by: on 2009-12-06 03:49:31
Document Title: Web Processing Service Version: 1.0.0
Proposal: WPS specification a lacking support for on-the-fly deployment of processes.

Posted by: on 2009-07-31 09:47:13
Document Title: Web Processing Service Version: 1.0.0
Proposal: Simplify and improve the WPS operations using KVP encoding. Conform with conventions compatible with REST.

Posted by: on 2010-02-26 05:18:18
Document Title: City Geography Markup Language (CityGML) Encoding Standard Version: 1.0
Proposal: It is necessary to realize the indoor 3D routing.