Proposal - constraints

General talk Tagging general discussion
1

Recently, I’ve been using a laser distance meter to measure the dimensions of indoor features like rooms and corridors, then adding them to OSM.

Currently, it’s unnecessarily tedious to add data this way - neither JOSM nor Vespucci have an easy way to say “I want a line or polygon with these dimensions”. And once you add data matching the dimensions, there’s no way to tell other mappers that a feature should have certain dimensions. I’ve been adding them as notes, but of course a mapper may ignore them. Nor are they machine-readable.

This reminded me of an idea I had documented earlier. Constraints - OpenStreetMap Wiki What are everyone’s thoughts about it?

A simpler subset

A simpler way to solve the immediate problem for indoor elements could be - instead of using closed ways, we construct a polygon by combining two-node-ways into a relation. These ways may be given a length=* tag; the other tags go into the relation.

The editing software should ensure that the ways remain at their given lengths at all times. If I perform a squaring operation after selecting all the ways, the squaring should be performed while respecting the length constraints of the ways. (If such an operation cannot be performed without breaking the length constraints, the operation should not be performed and the user should be informed.) Thus, the angle constraints described in the link become unnecessary for the most common case of 90° angles.

The ways don’t need to be two-node-ways (that’s just the most likely common case for indoor mapping). The length=* key could be used as a constraint for any kind of way in general, but I don’t know what uses that might have.

Conclusion

In either case, constraints will make addition and maintenance of data easier, and prevent errors before they are made.

What does everyone think of it? Are there better ways to solve these issues?

(In your responses, please specify whether you refer to the original constraints idea on the wiki page, or to the simpler subset described here. Also, alternative suggestions which alleviate the problems are preferable to just letting the status quo continue.)

2

Looks like duplication of information already mapped as geometry.
Could you elaborate what problems these constrains are supposed to solve?

I understand something along the lines:

  1. User A maps some building very precisely.
  2. User A adds constrains.
  3. User B moves geometry. Perhaps due to mistake.
  4. QA tool checks that constrains no longer hold.
  5. User A can fix geometry

I don’t think it’s worth the effort for this case. Extra complexity will make mistakes more likely

1 Like
3

Yes, the information provided by the geometry is certainly duplicated. However, in most cases the geometry of OSM data isn’t very accurate. When somebody has taken the time and effort to actually measure the dimensions of a feature, perhaps the duplication is a worthwhile tradeoff to ensure the geometry remains accurate to the measured dimensions.

A separate QA tool is not necessary - what is necessary is editing software support. Once the constraints are defined, the editing software ensures that the geometry respects the constraints at all times, and neither user A nor B can modify the geometry in such way that the constraints are violated. (To do so needs the constraints to be modified or removed first.)

It also helps the same user add more data. e.g. if I’ve made a room of certain dimensions, I want to be able to connect it to a corridor, without the editor accidentally breaking the geometry by moving the wrong node during node merging.

4

I generally like the idea and constraints would offer certein advantages without doubt. But I also agree with @starsep that constraints would add complexity to OSM and increase the risk of mistakes.

Thinking about very complex places like city centers with masses of objects on various levels + some indoor mapping PLUS a network of constraints gives me some headache. Additionally it would require very precise work because otherwise every necessary correction would cause additional work by first removing the contraints before being able to adjust the objects.

As I said I like the idea but I believe at the actual stage OSM is not yet ready for that.

3 Likes
5

Here is a JOSM script that makes a way of a specified length. You can rotate the resulting way, but if you move it to a different location on the globe the dimensions will be wrong.

6

To be honest I think a better solution is probably to draw it up in one of the free bits of CAD software and then import it. Not sure the best workflow, but I think I’ve seen something listed as supporting DXF.

I wish I could remember which of the 2D ones was decent. One started to have non-free components with a time limit if you didn’t buy.

7

I like the idea of constraints, have been dreaming about it for a long time (they could offer a way to iteratively improve the geometry, and help prevent iterative degradation of detail). There are several kinds of interesting constraints that could make sense: length, angle (e.g. define that neighbouring building walls are parallel), and alignment (e.g. define that front facades of buildings are in one line, or that a house is set back from this line by x meters, or that a building is in the middle of a road leading to it,…), and also elevation (a node with “ele” should not be arbitrarily moved without taking the ele into account).

Generally, if we are mapping carefully, and have discovered such relations and (virtual) lines/alignments, we can put them implicitly in the data (if the buildings are aligned, and you map accurately, they will line up in the map “automatically”), but there is no guarantee that they remain like this, someone may later edit them, e.g. move some buildings to align with current imagery but ignore other alignments with mapped objects.

Ultimately, it would lead to greatly raised complexity, and typically not so much practical benefit, so I do not think this is a direction that we will move to (any soon at least). If I were pursuing it, I would be more interested in alignments than in absolute values (for measurements, elevations, etc.). Anyway, nobody is stopping you right now from adding “8345 x 13440mm” to a building outline rectangle, but as soon as you add this kind of “precision”, it becomes relevant where exactly you measure (e.g. you may even get several centimeters of length difference for the distance of 2 parallel walls, simply because you measure at different heights or at different points), and looking in detail you will find out that we are generalizing the building outlines and that in reality there would be much more points to draw if you wanted to get the geometry “precisely” (i.e. even more complexity, for not so much gain, IMHO).

2 Likes
8

Ah yes, I love OpenStreetCAD unironically… Once, I saw some persistent “construction geometry” used to draw complicated buildings, so they already exists without specifying the dimension.
The issue is I suppose the CAD and GIS methods are different, without going too deep into fusion of eg BIM. I don’t know how they interact in the software there. Similarly, I’m not sure the constraint data is actually stored when you draw with constraints. Geometric constraints—ArcGIS Pro | Documentation
To be more precise in relative position, GIS uses cogo from land lots for surveying and engineering. Then again, there’s misclosure. The absolute position becomes important, not only coordinates and datum:horizontal= reference frame, but also the datum:horizontal:epoch= Revent/Key:datum - OpenStreetMap Wiki
In the data, the length is obtained between the coordinates of 2 points. Eg calibration:*= (used for =survey_point in Kenya) could be created somehow to show they are calibrated. Then the question becomes whether length= should be added for easy editing and data retrieval. However judging by similar logic, area size isn’t stored either, for other “geometric attributes” (in QGIS terms, which you have to add manually).
Disclaimer: I have tried using both laser measure and RTK GNSS. Haven’t added such data to OSM yet.

9

Having used CAD systems where the constraints solver has got confused and failed dramatically; I’m very wary of this.

If you have:

  1. a bunch of different software all trying to solve constraints every time something is edited,
  2. they are doing this on objects that may not have all the relationships loaded
  3. and you’re doing all of this in a WGS84 coordinate system that is, as I understand it, one of the fuzzier ones

then I think this might just be asking for trouble.