On 16.01.2015 11:40, Markus Lindholm wrote:
> What we don't need is yet another special case mapping scheme like addrN
>
> Have you had the time to look at the existing relation of
> type=provides_feature
> http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature
> and how you can use it to associate multiple addresses to a building.
Be aware that you are referring to another proposal that is not approved.
This bears the danger of circular disapprovals:
A is disapproved because B exists
B is disapproved because C exists
C is disapproved because A exists
That said, I'll give you my opinion on the provides_feature relation:
- It should include the {{Proposal_Page}} template and an RFC start date.
- It should include at least one example.
- The general concept seems reasonable.
- It's a relation. In most cases, it takes one relation per map feature.
That's too much.
- It relies on address nodes, which further increases the number of OSM objects.
We already have too many relations, and editing an area becomes harder and
harder. We always need to step through long lists of relations to make sure
we don't damage one. provides_features relations do not even have names, so
all we see in the relation list is a bunch of ids. Of course we can improve
editors to use different colors for different relation types. But wait - web
editors like Potlatch and ID don't display relations at all. Anybody using
these editors will damage the relations, or at least not create these
relations when needed.
With the addrN schema, we need one object (a node tagged shop=* and
addrN:*=*) for a shop.
With the provides_feature relation we need one node for the shop, one node
for each address, and one relation.
The mostly used argument against addrN is that it is not yet supported by
applications. The provides_feature relation is not yet supported either.
The provides_feature relation may be fine for entrances and parking places,
but using it for addresses adds too much unnecessary complexity to the
database. I am not sure if the "address" role is bad, but we shouldn't use
it in cases where we can do without that relation.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
