4

This is not a software-specific question, but rather a question about how to represent some concepts in a GML LineString.

It has to be GML, for policy reasons.

Consider a GML LineString consisting of contiguous segments. I'm trying to represent attributes that are valid for a segment, but not necessarily valid for the whole LineString.

As an example, it might be a car route along several roads. Each road on the route could have some different properties (surface, minimum and maximum speeds, width, surface roughness). My modelling scenario is quite different to the car route, so I'm not looking for something that is specific to that domain (e.g. the OSM model isn't going to work for this - it is not GML for a start).

Conceptually, the LineString could have some default attributes, which are overridden by per-segment attributes. In the car route example, the route might have a default speed, but some segments are higher or lower speed.

The concepts I've explored so far:

  • Using a LineString, and adding numbered attributes / elements.
  • Using a MultiLineString or collection, where each LineString is a single segment, attaching the attributes / elements to a LineString.
  • Using Points to implicitly represent the LineString, such that the attributes / elements on the Point apply to the next Point.

None of those seems very satisfactory (loss of explicit representation, possible gaps in the collection cases, non-obvious intent).

Is there published guidance on performing this kind of modelling (e.g. from OGC or ISO), or failing that, anything that is likely to be better supported in common tools / GML profiles than what I've already identified?

  • What do you want to model? You give the example of the car route, but then you say your modelling scenario is quite different to the car route. Can you give an example of what you want to model? – RHB Mar 15 '16 at 17:40
  • Also, do you mean that you want your sub-segments to have different values of the same attributes? Or, do you mean that you want your sub-segments to be able to have different attribute schemas from each other? – RHB Mar 15 '16 at 17:43
  • It would also be helpful to see XML snippets for the 3 things you have tried, so we can see what you are doing. – RHB Mar 15 '16 at 18:15
  • I can't share the exact scenario, but I'll try to find something similar. – BradHards Mar 16 '16 at 0:02
4
+100

This falls within the field of linear referencing. The spatial feature is represented typically as a single "centerline" and non-spatial records/elements are used to record attributes along that centerline with start and end measures. I see ISO does have a published specification.

ISO 19148-http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32566

See Chapter 9, Linear Referencing in https://portal.opengeospatial.org/files/?artifact_id=46568.

GML 3.2 (and other OGC specifications) so far mainly support 2-D and 3-D spatial locations. An alternative location scheme is to use linearly referenced locations, where a location is specified as being at a certain distance along (and perhaps offset from) a linear element. The linear element might be a feature which exhibits linear behaviour (i.e., it is linearly measurable), a curve type of geometry, or a directed edge type of topology.

  • Thats an interesting idea, which I hadn't considered. However I don't think its a 100% solution. My concerns are that linear referencing is typically a position (or subset of the linestring) and I'm really looking for a property of a segment. That is, if I change the length of an earlier segment, I wouldn't expect to need to update all the attributes that are not on the modified segment, which would be the case for typical linear referencing. – BradHards Mar 13 '16 at 0:35
4

@dhollema is guiding you to the right direction and fortunately it seems GML supports this data type. Note that LRS(Linear Referencing) is designed and developed for this specific type of applications. The first reason to use LRS is that Many organizations collect data about linear features as point locations along the line as an alternative to expressing the locations using x,y coordinates. Before using LRS you should be aware of some terminologies:

Route A route is any line feature, such as a street, highway, river, or pipe, that has a unique identifier and a system of measurement. Routes are stored in a route feature class. route types

Measure (m-values) A value stored along a linear feature that represents a location relative to the beginning of the feature, or some point along it, rather than as an x,y coordinate. Measures are stored as m-values on route vertices. Measures can be any unit of measurement, such as miles, meters, and time.

measures (m-values)

To address your comment on @dhollema answer, if you update the geometry of the route-e.g. by changing,adding or remove the vertices- it is the application duty (not the GML format) to re-calibrate the route with known measure values at specific locations on your map. By calibration I mean, to fit the new measure values to the route and interpolate in between the known measures. However there are cases that you change to geometry but the measures are intact (e.g. extending a road doesn't effect the pre measured m-values)

recalibrate

Events An event is a linear, continuous, or point feature that occurs along a route feature. Anything that occurs on or describes a route feature can be an event. In the transportation field, examples of events might include pavement quality, accident sites, and speed limits. Events are stored in event tables.

Dynamic segmentation Dynamic segmentation is the process of computing the map locations of events stored and managed in an event table along route features and displaying them on a map. The term dynamic segmentation is derived from the concept that line features need not be split (in other words, "segmented") each time an attribute value changes—you can "dynamically" locate the segment.

Using dynamic segmentation, multiple sets of attributes can be associated with any portion of an existing linear feature independently of where it begins or ends. These attributes can be displayed, queried, edited, and analyzed without affecting the underlying linear feature's geometry.

Dynamic segmentation

Disclaimer: Some of the information in this answer are from Esri doc.

  • As for my comments on the other answer - you've missed the point that I'm trying to model something that is explicitly a property of the segment, irrespective of the number / presence / length of other segments. I'm not saying it isn't possible to include this as an along-linestring length (or other property, as identified in the question), but its an indirect modeling, which I was trying to avoid. – BradHards Mar 14 '16 at 15:20
  • Then you can use OGC SFS (simple feature spec) with gml and model this behavior in your application. However you are talking about standard modeling to avoid application specificity. As you mentioned LRS is an overall solution and your application is a special case of LRS which doesn't have any event along the line-segment rather only at the vertices. – Farid Cheraghi Mar 14 '16 at 15:55
  • Conceptually the main attribute I'm trying to model is a property of the segment. Modeling it as a vertex property is indirect (e.g. if the path is reversed, I need to move all the attributes). Per the question, SFS LineString plus per-segment attributes is roughly the right concept, but not well supported in GML. – BradHards Mar 15 '16 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.