[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
anyway.
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.
--
Matthew
More information about the talk
mailing list