[Tagging] Wiki edits, building tags on nodes versus areas

Martin Koppenhoefer dieterdreist at gmail.com
Fri Jun 6 12:24:47 UTC 2014


2014-06-05 17:03 GMT+02:00 Tod Fitch <tod at fitchdesign.com>:
Tobias wrote:

> > Therefore I believe that the only really clean solution is to actually
> > create one OSM element per feature: one for each shop, and one for the
> > building. This is also future proof - want to also tag the level the
> > shop is on, or even do complete indoor mapping? You can!
>


+1



> > Now, I don't think this should be enforced in situations where there is
> > only one shop in the building and where the building itself doesn't have
> > name, wikipedia or other tags different from the shop's. But for the
> > general case, I'm still in favour of using multiple elements.
>


+1, it will work in simple situations and few details mapped to combine all
on the same osm-object, so it can be an accepted shortcut, but you'll have
to split the different things into different objects if you want to map the
details with established tags (the alternative, that I do not recommend,
would be to use namespacing like name:shop=* name:building=*
start_date:shop=* start_date:building=* etc.)




>
> How would you tag a shop within a shop?
>


just like any other A inside B: draw B and A where A is inside B and add
tags to A and B.

A node is generally a worse representation of something with clear extent
than is a polygon (or multipolygon), as it won't convey information about
the size, shape and orientation and won't permit to put stuff "inside".
This said, a node is often "good enough".

If you want to map a shop inside a building where the shop occupies the
whole building, and you want to do it cleanly (avoiding ambiguities) you
could for instance add the building tags to the way and make a multipolygon
(with one outer way, the building) for the shop. The alternative are
overlapping ways (a pita to edit) or a node for the shop (looses the
information that the shop uses the whole surface).

Btw.: I think we should also have a relation-type for nodes / points, so we
can do the same with nodes without having to overlap 2 nodes. This is
required if you have several point objects at the same spot, e.g. different
traffic signs (that you would want to map) on the same pole. Could be
called a multinode relation maybe? (In case there is also usefulness in
having more than one node in one object).
Are you aware if there is already something proposed for this?


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


More information about the Tagging mailing list