[OSM-talk] Mapping feature ideas (was: Funding of three infrastructure projects)

Matthew Woehlke mwoehlke.floss at gmail.com
Tue Aug 4 16:03:22 UTC 2020

On 04/08/2020 11.08, Martin Koppenhoefer wrote:
> On 4. Aug 2020, at 16:26, Matthew Woehlke wrote
>> Obviously, this would all almost surely be a temporary mode (maybe
>> it persists as long as JOSM is open, but isn't uploaded), but since
>> you usually draw once, that would be fine. (Bonus points if JOSM
>> could automatically recreate constraints for ways that don't have
>> any. It shouldn't be hard to guess equality, perpendicular and
>> colinear constraints, at least.)
> rather than guessing, I sometimes have wished there had been a way to
> actually store relationships (geometric) in the data, something like
> these buildings all align their front facades, or this door (or
> building position) is aligned to this street axis, etc., so when
> people moved the street, the building would move as well. Would
> become very complex if it would be used extensively (basically you
> might move the whole city by moving a node, or it could lead to
> unresolvable constraints, etc.), so I think it’s not gonna come. Just
> accept some fuzziness ;-)

Sure, I can see the use. I was thinking in terms of things that can be 
done without schema changes.

Besides the troubles of trying to resolve an overconstrained system 
(something I've run into with FreeCAD for systems that are probably much 
more simple than what OSM might become!), another issue is that editors 
that don't support the constraints — I'm looking at iD, mostly because I 
shudder to think of the complexity and performance of implementing a 
solver in a web browser! — will tend to break them often. So, I'm not 
going to hold my breath ;-).

> People are overrating rectangular buildings anyway, they might look
> more correct than a freehand approximation, but they typically aren’t
> (too short, too long, too wide, wrong angle not parallel to the
> street, not parallel to their neighbors, etc.), sometimes resulting
> from misinterpretation of aerial imagery and conscious or unconscious
> generalization (representing with a single rectangle what in reality
> is a rectangle with an oriel or a cutting or some other added shape).

Sure, I've seen some overly generalized buildings. I tend to model with 
more detail. (See for example 
https://www.openstreetmap.org/way/44931534, which is also a good example 
of where more constraints would have been useful; there are at least 
three axes of symmetry, and the four corners at the extrema of the 
longer axis *reeeeealy* look like they line up.) Still, we *do* tend to 
build things with right angles, so right angles are very often correct. 
At least for buildings. (Roads can easily get more sloppy.)

> And sometimes a lack of diligence (e.g. when a building is on the
> crossing of two roads which aren’t orthogonal, it is not unlikely
> that the building isn’t orthogonal either, and it might be easily
> visible in the imagery, but if you only have a hammer, you might be
> tempted to use it for the screws as well).

Well, that's a user problem :-). I've also run into many, many instances 
of things that seem like they *ought* to line up, but if aligning is 
noticeably different from the imagery, I won't force it. Most of what 
I'm picky about is within individual buildings, or stuff like aligning 
parking aisles in the middle of the spaces because it renders better and 
the way is (since it's a line, not an area) necessarily an approximation 

Conversely, I'll get a little more "sloppy" with placement, because I 
generally trace roof lines and then try to shift the shape to compensate 
for parallax and my best guess at how much the roof overhangs the wall. 
Again, see the previously cited example and compare how it lines up with 
the corners *on the ground* and not the roof line. See the adjacent 
https://www.openstreetmap.org/way/830822584 for an even more pronounced 
example; this one is straddling separate images that were stitched 
together, so there is a discontinuity in the parallax going through the 
middle of it. Constraints actually *help* here because I can make a 
reasoned guess at stuff like "these walls probably line up" and use that 
to try to deduce the actual shape when the imagery is messed up.

Of course, a lot of this will depend on the quality/resolution of the 
imagery available. On the US East Coast, MapBox is very high resolution, 
which help significantly. Trying to map to the level of detail I'm 
typically doing is probably not possible with lower resolution imagery.


More information about the talk mailing list