[Tagging] Possibility to draw parking properties as an area
pla16021 at gmail.com
Sat Mar 9 13:03:41 UTC 2019
On Fri, 8 Mar 2019 at 18:25, Martin Koppenhoefer <dieterdreist at gmail.com>
Right, there's this "incompatibility" of the highway graph with the rest of
> our data. There are efforts to map roads also as areas though, and sooner
> or later this kind of mapping will be established (in built up areas and
> particularly where the shape is not regular, so that it actually makes
> sense to do it, e.g. historic town centres).
"Sooner or later" is likely to be a lot later for much of the map. For
instance, I've mapped several
lay-bys (rest areas) from aerial imagery alone. They tend to be on very
long roads (otherwise
you wouldn't need to pull in for a break). Mapping the full extent of a
road with a lay-by as an
area would be very tedious, and there are far too many other things as yet
unmapped of more
> Your way, we'd have a gap between the parking area and the road when it
> no, just in the editor. In the rendering the parking area will probably be
> on the road ;-)
If you tweak it enough, and check at all zoom levels.
Which there isn't because in reality they're conjoined and contiguous.
> Your way, the parking area
> wouldn't be routeable.
of course you could route to the parking area. Every router does this all
> the time. We don't add housenumbers to the road, do we?
Theoretically (perhaps even it's already feasible in some apps) you could
route from the house
end of a driveway (selected by mouse click). You can't do that with a
disconnected parking area
unless the router makes guesses. But there could be roads adjacent to two
sides of a parking
space, only one of which actually connects to it and the router could guess
> generally our roads are thicker than they are in reality, only in the
> highest zoom levels this might change to the opposite. It is impossible to
> get this right in all zoom levels.
Indeed. But if the parking area connects to the road, it does get it right
at all zoom levels. Well,
right-ish. One of the reasons the renderer puts things at different z
indexes is so that things like
this end up looking right (ish) so that the parking space isn't shown as
extending to the middle
of the road.
> routing is not an issue, for the rendering results _might_ look more
> "clean" if you extend the parking up to the middle of the road (not that
> the representation would be more accurate though), but at the cost that the
> parking area will become much bigger than it actually is.
Just about everything in OSM could be done better. Usually with associated
costs, like mapping roads
as areas, and living with the fact that we don't have the time to do the
entire extent of every road that
way, so we'd get jarring width changes everywhere. We have to go with the
best solution we
currently have and live with the fact that the map is a stylized
representation. I see extending
the parking area to the highway as the best trade-off we have, you disagree.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging