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