Linear Referencing M Coordinates

[UserBlue1973]

Could the place object be enhanced to include Linear Referencing M coordinates?
Currently, the standard only includes three dimensions, not a fourth dimension, so GeoJSON isn't suitable for organizations like ours because our data is almost exclusively linear referencing data.

Related:

• https://gis.stackexchange.com/questions/431189/how-to-request-geojson-standard-be-enhanced-to-support-m-values
• https://community.oracle.com/tech/apps-infra/discussion/4498435/idea-sdo-util-to-geojson-support-lrs-geometries
• https://community.esri.com/t5/arcgis-roads-and-highways-questions/geojson-linear-referencing-m-coordinates/m-p/1479114

(synonyms: M values, M-enabled, LRS, linear referencing system, M dimension, fourth element)

[cportele]

Meeting 2022-07-11: Since we want to focus on the Core requirements for now, we consider this out-of-scope of the current Part 1. Most coordinates use XY or XYZ. Support for M has its applications, but is not a requirement that many have. We move this to "future work".

[larsbutler]

Hi @cportele, is there any mechanism for the wider community to give feedback on the linear referencing topic? While it may be true that most use cases don't require M-type geometries, those use cases do exist. This not only creates challenges for users, but it's also tricky for those who build/maintain libraries that handle geospatial data conversion. I'm the creator and on of the maintainers of https://github.com/geomet/geomet, and this topic keeps coming up over the years. I'm doing my best to support people who have these use cases, but without a complete, standard data format, there isn't much that can be done.

What's the blocker to including support for linear referencing (M)? Is it lack of interest, lack of data, or lack of solution? I'm happy to assist any way I can, even if it's just gathering data around this use case.

Thanks!

P.S. Is it the intention to submit this new standard as an RFC, either to supplement or override GeoJSON? Just curious.

[brownhoward]

While I agree there are more use cases that require Z rather than M, the latter use cases are not negligible. Having worked in GIS-T for many years, linear referencing is the standard way for maintaining attributes on a road network, and without support for M-type geometries it really limits the use of GeoJSON.

What is required for this to be reconsidered and brought forward?

[xlhomme]

Hello
A few years ago ESRI had proposed its ESRI-JSON format and a version of the OGC API (named GeoServices), but refused by the members of the OGC because it was proposed by ESRI, thus accumulating many years of delay and a considerable brake on standardization.
This consortium has left the hand to computer scientists to create standards allowing the transmission
geographical information without considering the real needs.

The JSON-FG format is an opportunity to catch up with the delays accumulated over many years by OGC standards.

Don't forget the M coordinates!
best regards

[cportele]

The working group discussed support for M coordinates in the meeting on 2024-04-29. We tentatively agreed to add support for M coordinates in an additional requirements class, if we can specify this in a way that is easy to use M coordinates.

In JSON-FG all coordinates of a geometry are in a coordinate reference system (CRS). A consequence is that if M coordinates are used in a geometry, the CRS would need to be a Compound CRS and include a CRS (EnginneringCRS) that is a linear coordinate system with a single axis (LinearCS) in addition to the 2D/3D CRS for X, Y and optionally Z.

A LinearCS as defined in OGC Topic 2 is a "one-dimensional coordinate system that consists of the points that lie on the single axis described" with the note "The associated coordinate is the distance – with or without offset – from the origin point, specified through the datum definition, to the point along the axis. Example: usage of the line feature representing a pipeline to describe points on or along that pipeline. A LinearCS shall have one axis association."

There is one catch. Each LinearCS has a datum representing the origin of the M values, e.g., the start of the line geometry of the pipeline or a road element. Since the M values in different geometries may be related to different origins, there would need to be a CRS for each origin.

This would not be possible with the current approach to only support CRSs that have been registered (typically with EPSG or OGC) and it would also make it quite complicated to use.

I see two options:

1. The CRS of the measure coordinates are not declared as part of the CRS (member coordRefSys), but through an additional member (e.g., "hasMeasures": true). This would be the simplest solution and in a way consistent with the Simple Feature Access Standard that only has a SRS/CRS for the X/Y/Z coordinates and for M just the information that they are included (isMeasured()).

2. The other option would be to define a 1D Engineering CRS with a Linear CS with unknown origin and unknown unit of measure. Similar to https://www.opengis.net/def/crs/OGC/0/Engineering2D for a CRS in an unknown 2D Cartesian CS.

In this case, the first option seems to be more appropriate as it is easier to use and consistent with the Simple Feature Access standard. The second option does not add more information about the measure, but is more difficult to use.

A variant of the first option could be to optionally include additional information about the measure, e.g. a description and the unit of measurement. In that case the new member would be an object, e.g., "measures": { "enabled": true, "unit": "m", "description": "Distance from the start of the road element" }.

[jratike80]

I believe that the measures, when they present linear referencing and not things like speed or air pressure at the vertex point, have usually a real world connection with the geometries in some CRS. Let's say that the linestring is in some UTM zone and then the computed length of the linestring is the same than the highest M value.

But if the geometry is re-projected into some other system, let's say into Gauss-Krüger that has a scale factor of 1 instead of 0.9996 of UTM, then the connection between the M coordinate and the cartesian length of the geometry itself is destroyed. How to inform users what M exactly means?

"measures": { "enabled": true, "unit": "m", "description": "Distance from the start of the road element", "crs-m":"EPSG:32655" }

I think that it is unrealistic to require that for example OGC API Features servers would re-compute M values if the request crs in not the storage-crs.

[cportele]

Meeting 2024-05-27:

• We tend to prefer the first option with an object that can include information about the unit and a description.
• Regarding the behavior in case of conversion to a different CRS, we think that the DBs will not change the M values (to be checked), so we would not expect that an API would change the M values, if the data is requested in a different CRS.
• @cportele will draft a PR, to be discussed at the OGC member meeting (if we can find a slot).

[xlhomme]

Hi Our use case is as follows: M is used to store the kilometer position along a railway line. Where the sign was positioned. This does not necessarily correspond to the linear distance from the start. Some points are fixed and others are interpolated between the defined points. We need to have an M<->Geo converter, because the firefighters find their way in relation to the sign indicated on the railway. best regards Le lun. 27 mai 2024 à 16:52, Jukka Rahkonen ***@***.***> a écrit :

…

I beleive that the measures, when they present linear referencing and not things like speed or air pressure at the vertex point, have usually a real world connection with the geometries in some CRS. Let's say that the linestring is in some UTM zone and then the computed length of the linestring is the same than the highest M value. But if the geometry is re-projected into some other system, let's say into Gauss-Krüger that has a scale factor of 1 instead of 0.9996 of UTM, then the connection between the M coordinate and the cartesian length of the geometry itself is destroyed. How to inform users what M exactly means? "measures": { "enabled": true, "unit": "m", "description": "Distance from the start of the road element", "crs-m":"EPSG:32655" } I think that it is unrealistic to require that for example OGC API Features servers would re-compute M values if the request crs in not the storage-crs. — Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6NJZC4BPLNII5J346NPSDZENCETAVCNFSM5WOIHBNKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGM3DIMJVGEYQ> . You are receiving this because you commented.Message ID: ***@***.***>

[jratike80]

Are there any natural use cases for POINT M and POLYGON M? Times, perhaps. Should the unit be Unix epochs or what?

I think it is rather easy to make bad things for the linear referencing with standard GIS tools. Split or merge linestrings and M values have no meaning. But of course that does not happen if the users knows what they are doing.