<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Martin, hi Stewart,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> 3. After the upload, we'll review the 200 or so buildings that need fixing. These will be small fixes as explained above.<br><br>
</span>I think it would be better to trace actual building outlines rather than generate generic placeholders from single nodes, </blockquote><div><br></div><div>Of course. However, it was a significant effort to mark the 3200 buildings, and it's impossible for me to manually trace 3200 buildings.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">better have fewer buildings but actually traced. </blockquote><div><br></div><div>Only from a certain perspective :) The health workers we work with need to primarily know where buildings are. Of course, the nodes would suffice for that. However, node[building] doesn't render in standard carto, hum carto, or <a href="http://maps.me">maps.me</a>. OSMAnd does it, but is too complex for the health workers. I did discuss rendering node[building] on github, but the view is that node[building]  should not be rendered.</div><div><br></div><div>So what's the practical solution, for us to support the health workers? Expanding buildings would make it work in <a href="http://maps.me">maps.me</a>, and be quite correct for 90% of the buildings (I'll send you some screen shots off list, including existing buildings) - but yes, ultimately it's "mapping for the renderer".</div><div><br></div><div>We will also print maps (c.f. my earlier questions on another list), and obviously we'll have influence over the rendering (if we figure out how to do it), but that's only printed maps. However, digital maps are needed too.</div><div><br></div><div>Any further thoughts?</div><div>Bjoern</div></div><br></div></div>