> Coconino's boundary IS rendering, but with more accurate tags, and differently than a national_park
That's incorrect. It's not rendering at all on the highest zoom levels, which have been refreshed most recently. boundary=national_park and boundary=protected_area are rendered identically in the relevant map style: https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/admin.mss#L496 - Joseph Eisenberg On Thu, Jul 16, 2020 at 10:55 AM stevea <[email protected]> wrote: > On Jul 16, 2020, at 10:13 AM, Joseph Eisenberg <[email protected]> > wrote: > > It's not the tagging. Other relations with boundary=protected_area + > protect_class=6 are rendering fine in the OpenStreetMap Carto style. The > code is here: > https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149 > - boundary=protected_area + protect_class=6 is enough. > > To repeat myself, I believe Joseph and I agree / are saying largely the > same thing here: there isn't anything to "fix," as boundary=protected_area > + protect_class=6 renders fine in Carto, and that is how Coconino is now > (more correctly) tagged. > > Given the recent history of this multipolygon's tags being changed from > national_park to protected_area (both of which render, but slightly > differently), if original poster Paul wants to add clarity to why he > believes this "isn't rendering anymore" I welcome what he might add or > additionally ask. However, I believe the relevant issues to be addressed > have been. The answer is "Coconino's boundary IS rendering, but with more > accurate tags, and differently than a national_park, which is how it was > previously though incorrectly tagged." > > SteveA
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
