Oracle Spatial LRS point X and Y.

Question

I’m having some problems with LRS points.
Two tables: A and b. Table A contains valid LRS linestrings; table B (non spatial) is a list of points with stated eastings and northings columns that exist in close proximity to the linestrings. Points are associated to the linestring by a.unique_id.
I’m successfully projecting the b.points onto their a.linestrings using SDO_LRS.PROJECT_PT passing the a.geometry and constructing a geometry from b.eastings and b.northings.
So far so good. I can get the measure by nesting SDO_LRS.GET_MEASURE; and offset with SDO_LRS.GET_OFFSET. Meaning that the returned value from SDO_LRS.PROJECT_PT is a valid LRS point (SDO_GTYPE=3301):
(3301, 81989, (0, 0, ), (1, 1, 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ), (525121.71247406, 185976.696321595, 21.4631188722804, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ))
This is my problem: how do I extract the X and Y from the SDO_LRS.PROJECT_PT returned value?
This work so far:
SELECT a.unique_id,
b.point_id,
SDO_LRS.GET_MEASURE
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
ABS(SDO_LRS.FIND_OFFSET
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
FROM road_network a,points b
WHERE a.unique_id = b.roads_id
I’d like to add the following selections but it does not work:
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
).SDO_POINT.X,
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
).SDO_POINT.Y
And this one neither (just a couple of brackets, sign of desperation!):
(SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
)).SDO_POINT.X
(SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
)).SDO_POINT.Y
It always returns 0.
When you look at the SDO_LRS.PROJECT_PT returned value you’ll see the following only ordinates: 525121.71247406, 185976.696321595, 21.4631188722804
525121.71247406 being the X;
185976.696321595 the Y; and
21.4631188722804 the LRS measure.
So, how do I get those X and Y as part of my query results? Thanks.
Edited by: JG1981 on Jun 25, 2010 3:30 PM

Answer 1

A bit of time has past... I got back to this piece of work again. Thanks for the tips above, I’ve successfully implemented some of those. It works, but it’s too slow for production.
To summarise, this is the real world problem I’m dealing with:
Let’s say I’ve got a table containing pedestrian’s footways; each footway is referenced to its road network section (link), many footways records to one section. I have to calculate the length of each individual footway along its road section.
Theoretically this is done by projecting all the footway vertices onto its road section and returning the difference between the highest LRS value and the lowest. The problem is slightly made worse by the fact that each footway polygon can actually be made up of multiple elements (multipolygon).
The following is a sort of high level logic. I’d like to know if any of you agree with this:
1.     A temporary table t is created and populated with the following columns:
a.     Footway_id  existing identifier;
b.     Element_id  sequential and unique to the footway record;
c.     Vertices  LRS point (projected point);
2.     The table t is then queried: for each footway[sum[ each element (maxLRS-minLRS)]], in short, for each footway multipolygon the length of each element is added together to give the total length of the footway.
Is this too clumsy? Is there another way to go about? Perhaps without the use of a temporary table? Any suggestion’s welcome.
Thanks