[Tagging] Railway=station + area=yes questions:

[Martin Koppenhoefer]

2016-10-03 21:54 GMT+02:00 Alexander Matheisen <AlexanderMatheisen at ish.de>:

> The main problem I see for mapping stations as areas is the lack of
> defined boundaries. Compared to other types of POIs, the definition of
> a "station area" strongly differs depending on the background of the
> mapper and the use case.
>


most/many stations are fenced, using the fence perimeter will typically
give you a very good polygon approximation for a minimum size, especially
compared to a single node with no spatial extent at all.



>
> If you map the station from a passenger view, you would draw an area
> containing the platforms, the station building and maybe a bit more or
> less, depending on the mapper's definition of station. I think that
> such an area should not be mapped because it is possible to generate it
> by creating buffers around platforms, station building and station
> node.
>


creating a buffer is error prone, based on generalized assumptions and will
likely lead to smaller than desirable polygons (or bigger, if you use a big
buffer), it will always be a compromise.




>
> If you map the station from the view of railway staff, the extend of a
> station is well defined, but that is often far more than the area which
> is relevant for passengers.
>


IF the station area is well defined (what you seem to confirm), it is only
a question of finding out this defined area. Just do it like we map
everything: start with a best guess and iteratively improve your first
version later on.



> There is also the problem that e.g. if you
> want to render a caption and use the centroid for placement, the
> caption will often not appear at a correct position.
>


this has nothing to do with how to best map something, it is a rendering
problem (and "correct" in this context is 100% subjective).

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20161004/2f2af4db/attachment-0001.html>