Questions on the LRS network model.

Question

On page 6-26 of the "Oracle Spatial Topology and Network Data Models" documentation, the example shows that measures are recorded in the 'roads' table (i.e. the one with the geometry of the feature).
1. Why in this example is 'null' used for Node 5 ('...automatically calculated and filled...') but not the others?
2. Why in this example is measure even necessary? There is no link to the underlying route from this table (i.e. measures should only be recorded in the context of a given route).
3. It seems like this measure is merely the offset from the starting vertex (not true LRS); do we have the wrong interpretation?
On Page 6-30, the example shows that measures are recorded for each Node and each Link. We had envisioned nodes and links being separate from the route they play a role upon. For example, if the same node was part of two distinct routes, does this mean storing two rows in "road_nodes"? But they're the exact same location and the same node in our network. The same question applies to the 'road_links' table. If the answer is 'duplicate the rows' in nodes and links (once per route), why doesn't 10g Spatial record 'measure' in the "road_paths" table? Note that, on page 6-31, it says that it is '...for possible future use...'...
This example also implies the rows in the roads table are replicated as the (m)easure of the geometry column would change based on the route involved? If this is not the case why store the measure in the geometry column at all?

Answer 1

Hi,
My name is Gary Wong, and the original poster was asking these questions on my behalf. I'd like to continue the thread below in-line....
A: This is a basic LRS concept. You can have some NULL
measure values, and LRS can compute the actual measure
corresponding to a NULL value. This has nothing to do
with Network modeling, so you can assume a valid
measure value here for this example.So this was just an example showing both 'manually calculated and entered' and 'let Spatial figure it out'? As this is merely the offset from the starting point, wouldn't a user always use NULL to let Spatial figure it out? It seems like this model will always use whole links in a contiguous fashion, so when would the measure not be the cumulative total?
2. Why in this example is measure even necessary? There
is no link to the underlying route from this table
(i.e. measures should only be recorded in the context
of a given route).So in this model (and example), the entry in roads is the route itself? Other LRS models allow the re-use of a common route, so multiple entries in the roads table would reference the same route (in another table). A real-life example is a single straight road that has different names, or has different road surface, or road classifications.
Folowing this example, if I wanted to spatially reference some other business attribution on an existing route, say R1, would I have to create another entry in roads and duplicate the data? Even if it has the same start/end locations and path?
A: Measure is always an offset from the start vertex
and this is true for any LRS system. I am not sure what
you mean by "not true LRS".My mistake in using these words; there is no true LRS, just different models/implementations of it =8^). Other LRS systems can have a measure beginning, say 2.5 metres after the starting node (node, not vertex; I define a vertex as as one of co-ordinates defining the link, and node as a topologically significant vertex such as the start and end vertices).
Hmmm, does this answer my first question above? If you wished to start a road (as per the example) slightly off of a node, would you enter a non-zero measure as the initial co-ordinate?
Assuming I'm on the right track (i.e. cannot re-use a route), does anyone know if Oracle plans to implement this kind of LRS in 10g Spatial?
I see a cryptic ".. for possible future use..." reference on page 6-31 regarding the create_path_table() and create_path_link_table() methods.
Is this future use to allow multiple uses and references of a route?
Thanks and sorry for the loooong email..
gary