locked
Can the reduce method preserve the Z & M values from the original geography RRS feed

  • Question

  • I have just been looking at using the Reduce method as a quick way of simplifying my gps tracks. Each point was also created with elevation data (Z) and something in the M property.

    Having looked at the returned data from the reduce method, it appears that the elevation and m data is not present in the return geography.

    SHort sample below (explicitly truncated for brevity)

    {LINESTRING (-2.380194 52.0351444 107 0, -2.380209 52.0351452 107 1, -2.3802236 52.0351395 106 2, -2.3802889 52.0350405 103 3, -2.3803359 52.0349602 102 4, -2.3803868 52.0349192 103 5, -2.3803686 52.0348862 103 6, -2.3803349 52.034823 102 7, -2.3802784 52.0347733 102 8, -2.3802775 52.0347536 102 9, -2.3803468 52.0345262 102 10, -2.3804644 52.0341737 102 11, -2.3805053 52.0340697 102 12, -2.3807834 52.0339334 102 13, -2.3808923 52.0339205 102 14,

    resulting string is

    {LINESTRING (-2.380194 52.0351444, -2.3839085 52.033849, -2.3800741 52.0409757, -2.3888309 52.0408382, -2.3759567 52.050342, -2.381504 52.0415053, -2.3791857 52.0436429, -2.355939 52.0394129, -2.3588026 52.0355216, -2.3635394 52.036592, -2.3566131 52.0399091, -2.3619155 52.037573, -2.3678983 52.0402278, -2.3756702 52.0317397, -2.3800609 52.0352856)}

     

    thanks

    Ian

    Saturday, June 26, 2010 4:10 PM

Answers

  • Hi,

    This is by design. Please refer to the following descriptions from BOL:
    Z-coordinates are not used in any calculations made by the library and are not carried through any library calculations
    M values are not used in any calculations made by the library and will not be carried through any library calculations.

    References:
    Z (geography Data Type)
    http://technet.microsoft.com/en-us/library/bb933913.aspx
    M (geography Data Type)
    http://technet.microsoft.com/en-us/library/bb933966.aspx

    If you have any more questions, please let me know.
    Thanks.


    ***Xiao Min Tan***Microsoft Online Community***
    • Marked as answer by Ian Hamlet Tuesday, June 29, 2010 9:02 AM
    Tuesday, June 29, 2010 7:40 AM

All replies

  • Interesting find... given that the points in the result of Reduce() should be formed from a subset of the original supplied geometry, I can't think of a good reason why Z/M values could not be preserved for those points. If I were you, I'd raise a connect issue to get a response from the SQL Server product team on this request:
    https://connect.microsoft.com

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Tuesday, June 29, 2010 7:15 AM
    Answerer
  • Hi,

    This is by design. Please refer to the following descriptions from BOL:
    Z-coordinates are not used in any calculations made by the library and are not carried through any library calculations
    M values are not used in any calculations made by the library and will not be carried through any library calculations.

    References:
    Z (geography Data Type)
    http://technet.microsoft.com/en-us/library/bb933913.aspx
    M (geography Data Type)
    http://technet.microsoft.com/en-us/library/bb933966.aspx

    If you have any more questions, please let me know.
    Thanks.


    ***Xiao Min Tan***Microsoft Online Community***
    • Marked as answer by Ian Hamlet Tuesday, June 29, 2010 9:02 AM
    Tuesday, June 29, 2010 7:40 AM
  • Point taken, though i like most people interpreted the above as any calculations and methods ignore any values in the Z and M properties, rather than we will actively discard them.

    However it is what it is and I am sure there are very real reasons for it when you really understand what is going under the skin, it is just a little surprising and don't feel quite such a numpty if tansohimi was of the same opinion.

    Thanks once again for clearing up the issue.

    regards

    Ian

    Tuesday, June 29, 2010 9:07 AM
  • I had noticed this a while back and asked. I was told that linear referencing may be included in the future. This problem is related to linear referencing. The functions need to interpolate new values for the M and Z when these are run. For instance, during an intersection of a line with M and Z and a polygon, the new result could be a line split within the boundaries of the polygon. The M at the begin point and end point need to generated by interpolation when the polygon intersected between the point before and after the polygon crossed the line. If the begin point's M was 0 and the next point's M was 10 and the polygon crossed exactly in the middle, the new value would be calculated using a Linear referencing engine to get a value of 5. All the other points on the line within the polygon would retain their original M except for the first and last points which are new and get new interpolated values. The same thing would need to be done with Z but in a 3D enviroment. I really don't know how that would work. I've never check out how Z's get maintained in other GIS software since we normally don't use them.

    Currently, Sql Server is storing what is called a "dumb" spatial object, meaning M and Z values are not calculated with acted on by functions. They would have to create flags in the spatial objects making the "M-Aware" and "Z-Aware", to tell functions to do something with the data to handle those values.

    To resolve this problem, because we will eventually move our data to SQL Spatial, I am in the process of building a dll, to deploy into SQL Server, using the .NetTopologySuite which has Linear Referencing functions to interpolate the XYs at the point of intersection with the original line and return the new M. It's the only work around. Maybe one day MS will add this functionality.

    Thanks,

    Dion

    Wednesday, June 30, 2010 8:03 PM
  • I understand why interpolation of Z/M coordinates needs to be taken into consideration for functions such as STIntersects(), but can't see why that limitation should apply to the Reduce() function...

    The Douglas-Peucker algorithm used by Reduce() iteratively removed outlying points to simplify a shape - let's say that the original shape had 10 points - each with X, Y, and Z values. If the Reduce() algorithm removes every other point, why can't the remaining points retain their assigned Z values? Seems reasonable to me.

    Ian - if you still need this functionality, I would still raise it as a new feature request via Connect.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Wednesday, June 30, 2010 8:19 PM
    Answerer
  • I agree. If the remaining points are not directly affected by the operation, it should retain its values. I haven't tested it enough to see if that's how the objects are returned in other functions. I personally would like to see this feature corrected if it was an error or added as an enhancement.

    Thanks,

    Dion

    Friday, July 2, 2010 3:10 PM