[Tagging] capital and state_capital: how are they being used in your country?

John Packer john.packer7 at gmail.com
Thu May 15 20:02:23 UTC 2014


>
> So I say let's ban capital=* and admin_level=* on the place nodes!
>
We started this discussion because a user pointed out that it can be
incredibly inefficient for a renderer to find out using only relations if a
place node is a capital or not.

Furthermore, we cannot ban the key capital=* from nodes because there are
places where all they have is the node (without relations to represent the
city).

Yes, the key capital can be redundant, but it's not frequently used, and
has considerable benefits for the renderers, so personally I thinks it's
worth it.

Adding the key capital when it's not the case, simply to gain more
visibility in the map, is either vandalism or ignorance (or lack of
documentation) as far as I know, so it's not a problem exclusive to this
key.

The fact that the key capital does not point out which state/country it
belongs to is not a problem, because this information is available in the
boundary relation (using the admin_centre role).
That's also why it was pointed out that if the place if capital of both the
state and the country, capital=2 is enough. Because the key capital=* is
meant to help the renderer (and possibly to help people easily find
capitals in a search).



2014-05-15 16:08 GMT-03:00 Fernando Trebien <fernando.trebien at gmail.com>:

> On Thu, May 15, 2014 at 3:01 PM, Colin Smale <colin.smale at xs4all.nl>
> wrote:
> > It is not actually an attribute of the place at all, because if you
> > moved the place to e.g. the middle of the Atlantic Ocean it would no
> longer
> > be a capital. It is an attribute of the relationship between the place
> and
> > an (administrative) area. So the place and the area (represented by a
> > relation in OSM) may reference each other, for example by including the
> > place in the relation with a role such as admin_centre. Because a place
> > cannot be a capital in and of itself (it can only be a capital OF
> somewhere)
> > putting these tags on the place node is a denormalisation - to make
> things
> > more convenient for the data consumers, so they don't have to go through
> the
> > relations to see if a place is a capital or not. Such denormalisations
> are
> > not always a Bad Thing (it's a balance), but there must be an acceptance
> > that there is only One Truth, and zero or more derivatives. The One Truth
> > would be in the relations and we will need a mechanism (or at least an
> > algorithm) to derive the tagging for the place from the relations which
> > reference it.
>
> +1
>
> Note: because apps need to support certain kinds of relations (turn
> restrictions, multipolygon rendering, etc.), it "should be easy" (as
> far as I can imagine the algorithm) to extend such support (without
> sacrificing performance) to figure out whether a city is a capital by
> reading the list of members of the relations the city's node is a
> member of.
>
> > capital=2 only means it's the capital of A country. Without a link to the
> > country in question, this tag could be misused to increase prominence on
> the
> > maps, AKA "mapping (incorrectly) for the renderer", which is "frowned
> upon".
>
> +1
>
> > So I say let's ban capital=* and admin_level=* on the place nodes!
>
> I tend to agree, and I don't see yet any practical situation where
> using those tags is absolutely necessary and reading from a relation
> is not possible/too difficult.
>
> > Colin.
> >
> >
> >
> > On 2014-05-15 19:36, fly wrote:
> >
> > Am 15.05.2014 18:32, schrieb Andreas Goss:
> >
> > Am 5/15/14 16:30 , schrieb fly:
> >
> > Regarding the original discussion I am in favour of using
> capital=[2-10]* if
> > an additional tag is needed.
> >
> > I meant additional to the roles for the boundary relation above (cutted).
> >
> > admin_centre for 1 or more nodes
> > capital if not equal to admin_centre or more than one admin_centre
> present.
> >
> > The semicolon (;) is defined as value separator so we could have
> > capital=4;6;8 or similar.
> >
> > This just sounds like a disaster waiting to happen. I also don't see why
> it
> > would be needed. You are doubling the risk of errors when it comes to
> > admin_levels. Now you don't just have to ensure all relations are
> correct,
> > but also all nodes.
> >
> > As we are talking about admin_level (<-> capital) on nodes and it was
> > mentioned that it might be easier to use and I am not sure if it is used.
> >
> > If any I would go with capital=* and not admin_level=*
> >
> > You also have no reference to those numbers. When you add one
> admin_level to
> > a relation that relation has a name (Bavaria is a state). When placing
> > admin_centre you know the name of the relation and of the city so you can
> > make a connection (Munich is the capital of Bavaria). And while that
> maybe
> > is obvious at level 2 and 4, it becomes more compicated when you get into
> > smaller administrative areas. This also makes it more complicated to find
> > errors in the first place. I also bet that people are going to assume
> that
> > some numbers are missing and are simply going to add them, especially as
> it
> > varies from country to country, from state to state etc. Others might
> simply
> > add a number with good intend, because they had the wrong admin_levels in
> > mind.
> >
> > Cheers fly
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140515/96b69d7f/attachment.html>


More information about the Tagging mailing list