Hello,
Am 04.01.2013 14:43, schrieb dies38...@mypacks.net:
I recently created a waterway where I put the name of the waterway on the
relation but not on the component ways which are grouped by the relation.
To me, not duplicating data would seem to be the better overall practice, and
I wanted to tag a GNC franchise outlet in the United States and wasn't quite
sure what value to use for the shop key. I find that I'm not alone. Using
OpenLinkMap, I identified most of the current GNC outlets mapped in the US and
recorded the key:shop values ... all of the variants appeared
2013/1/6 dies38...@mypacks.net:
I wanted to tag a GNC franchise outlet in the United States and wasn't quite
sure what value to use for the shop key. I find that I'm not alone. Using
OpenLinkMap, I identified most of the current GNC outlets mapped in the US
and recorded the key:shop
...why do you duplicate the tag waterway=river on every way
Because the relation can contain more than simply the waterway. For instance,
one could add the riverbank, islets, and slips if one were so inclined. By
letting each component way retain an identity of what it is, the relation
Hi ceyockey,
Am Freitag, den 04.01.2013, 08:43 -0500 schrieb dies38...@mypacks.net:
I recently created a waterway where I put the name of the waterway
on the relation but not on the component ways which are grouped by
the relation.
This results in the name of the waterway not appearing in
In an earlier message it was suggested that I use key:brand for a store in a
chain. An alternative is to use key:franchise. Key:Brand is (much) more
widely used in terms of instances. Key:franchise implies a conservation of
business model by franchisees and goes along with a shared brand;
Thanks for the several comments from people. I decided to remove the relation
and name each component way individually. I referred to this conversation in
the changeset meta-data (source and source_ref). Regards --ceyockey.
-Original Message-
From: Werner Hoch werner...@gmx.de
Sent:
On Sun, Jan 6, 2013 at 3:54 PM, Werner Hoch werner...@gmx.de wrote:
AFAIR there's currently no relation type that inherits it's tags to the
member ways, so that the name tags are rendered on the map.
Relations with type=multipolygon render the name tag on the map.
(Replying to the entire conversation thread)
The way I see it: No data about the objects themselves should be in
changeset description - changeset should only describe the *change*
itself. Because - at least to me, but I do expect to many others as
well - it makes the database structure more
I posted the original question/comment and have been testing a switch over to
providing source information _only_ on changesets. I posted a followup message
which related the source-on-changeset matter to provenance in RDF data .. I
think that the source-on-changeset is as valid as and more
On Sun, Jan 6, 2013 at 12:51 PM, dies38...@mypacks.net wrote:
I wanted to tag a GNC franchise outlet in the United States and wasn't quite
sure what value to use for the shop key. I find that I'm not alone. Using
OpenLinkMap, I identified most of the current GNC outlets mapped in the US
11 matches
Mail list logo
