Changes between Version 1 and Version 2 of FDORfc11


Ignore:
Timestamp:
09/13/07 08:29:08 (17 years ago)
Author:
danstoica
Comment:

Clarified the behavior in the case of geodetic data

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc11

    v1 v2  
    1010||RFC Template Version||(1.0)||
    1111||Submission Date||Aug 03, 2007||
    12 ||Last Modified||Thomas Knoell [[Timestamp]]||
     12||Last Modified||Dan Stoica[[Timestamp]]||
    1313||Author||Thomas Knoell||
    1414||RFC Status||Draft||
     
    2424== Overview ==
    2525
    26 This RFC follows from RFC 8 by adding two geometric functions. RFC 8 laid the foundation for a common set of functions that providers could support. That RFC left out two commonly used geometric functions, ''Area()'' and ''Length()''. This RFC adds those two functions. A reason for adding these functions in a separate RFC is that there are coordinate system considerations that need to be defined and discussed that do not apply to the list of functions in RFC8. Many providers do not include a coordinate system library internally (e.g. SHP, SDF) while other providers (e.g. Oracle) do include a coordinate system library. ''Area()'' and ''Length()'' calculations on geometry with geodetic coordinate systems require a coordinate system library to do the spheroid-based calculations to provide correct results. While most coordinate system libraries include a distance calculation on the spheroid, most do not include area calculation on the spheroid. It is the proposal of this RFC that providers that do not use coordinate system libraries simply return simple calculations directly against the lat/long data (i.e. using Euclidian geometry based calculations). We would like feedback from the discussion list on the handling of this.
     26This RFC follows from RFC 8 by adding two geometric functions. RFC 8 laid the foundation for a common set of functions that providers could support. That RFC left out two commonly used geometric functions, ''Area()'' and ''Length()''. This RFC adds those two functions. A reason for adding these functions in a separate RFC is that there are coordinate system considerations that need to be defined and discussed that do not apply to the list of functions in RFC8. Many providers do not include a coordinate system library internally (e.g. MySql, SHP, SDF) while other providers (e.g. Oracle) do include a coordinate system library. ''Area()'' and ''Length()'' calculations on geometry with geodetic coordinate systems require a coordinate system library to do the spheroid-based calculations to provide correct results.
     27
     28It is the proposal of this RFC that providers that do not use coordinate system libraries to use instead calculations based on general accepted formulae to compute the geodetic distance for ''Length()'' and use Euclidian calculation based on geodetic distance for ''Area()''. This will also be the case when a provider native ''Length()'' or ''Area()'' implementations are found not reliable or defective.
    2729
    2830
     
    4648 * if the provided geometry is a polygon, the result is the length of the perimeter which includes all exterior and interior loops.
    4749
    48 For non-geodetic systems and if the provider is ignoring the handling of geodetic coordinate systems, the function ''Length()'' will return XY units while ''Area()'' will use the square of the length units. If the provider has a coordinate system library for geodetic coordinate systems, the length will be expressed in meters, the area in square meters.
     50For projected systems or for unknown coordinated systems the function ''Length()'' will return XY units while ''Area()'' will use the square of the length units.
    4951
    50 It should also be noted that the functions execute 2D calculations only. Therefore, if an object is defined in space, the functions should not be used to determine the area or length of such an object.
     52For geodetic systems, the length will be expressed in meters and the area in square meters.
     53
     54The functions will execute 2D calculations only. Therefore, the Z value will be ignored.
     55
    5156
    5257Like the standard functions listed in RFC 8, the user can get access to the geometric function definitions via the FDO interface ''!GetWellKnownFunctions''. The new functions will be categorized as geometry functions (''!FdoFunctionCategoryType_Geometry'').