Re: [OSM-talk] admin_level 4 rendering
Thank you everybody! Finally I could resolve this, with the kind help provided in this issue: https://github.com/gravitystorm/openstreetmap-carto/issues/633 Labels need a place=state tag in order to get rendered. A deeper discussion about how place areas should be rendered can be found here: https://github.com/gravitystorm/openstreetmap-carto/pull/546 Cheers, Felix On 04/08/2014 09:55 PM, Pierre Béland wrote: Felix, A by the nose recipe that you can try is to force update of the relation by simply modifying the order of the members in the list for the relation. After you save this relation, it will force the renderers to update for this relation. I had such suggestions once and it did fix my problem. Pierre *De :* Felix Delattre m...@delattre.de *À :* *Cc :* Talk Openstreetmap talk@openstreetmap.org *Envoyé le :* Mardi 8 avril 2014 17h23 *Objet :* Re: [OSM-talk] admin_level 4 rendering On 04/08/2014 02:36 AM, Martin Koppenhoefer wrote: 2014-04-07 21:41 GMT+02:00 Paul Norman penor...@mac.com mailto:penor...@mac.com: Subarea members are a pain and duplicate geographic information, +1, avoid them as they do not add something what would not already be said otherwise. cheers, Martin Subareas still seem to be used in a lot of countries, such as, those I ran into casually: USA: http://www.openstreetmap.org/relation/148838 France: http://www.openstreetmap.org/relation/2202162 Ukraine: http://www.openstreetmap.org/relation/60199 But checking other countries such as Germany, Switzerland and Haiti I can see that it is not there. I removed those subareas from the Nicaragua country relation and specified is_in=Nicaragua to the admin_level=4 relations. But, anyway this doesn't seem to have anything to do with the rendering. Is it right that this label rendering is happening only once in a while? Should we just wait, or is there something wrong with out data? Thank you! ___ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
2014-04-07 21:41 GMT+02:00 Paul Norman penor...@mac.com: Subarea members are a pain and duplicate geographic information, +1, avoid them as they do not add something what would not already be said otherwise. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
On 04/08/2014 02:36 AM, Martin Koppenhoefer wrote: 2014-04-07 21:41 GMT+02:00 Paul Norman penor...@mac.com mailto:penor...@mac.com: Subarea members are a pain and duplicate geographic information, +1, avoid them as they do not add something what would not already be said otherwise. cheers, Martin Subareas still seem to be used in a lot of countries, such as, those I ran into casually: USA: http://www.openstreetmap.org/relation/148838 France: http://www.openstreetmap.org/relation/2202162 Ukraine: http://www.openstreetmap.org/relation/60199 But checking other countries such as Germany, Switzerland and Haiti I can see that it is not there. I removed those subareas from the Nicaragua country relation and specified is_in=Nicaragua to the admin_level=4 relations. But, anyway this doesn't seem to have anything to do with the rendering. Is it right that this label rendering is happening only once in a while? Should we just wait, or is there something wrong with out data? Thank you! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
Felix, A by the nose recipe that you can try is to force update of the relation by simply modifying the order of the members in the list for the relation. After you save this relation, it will force the renderers to update for this relation. I had such suggestions once and it did fix my problem. Pierre De : Felix Delattre m...@delattre.de À : Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Mardi 8 avril 2014 17h23 Objet : Re: [OSM-talk] admin_level 4 rendering On 04/08/2014 02:36 AM, Martin Koppenhoefer wrote: 2014-04-07 21:41 GMT+02:00 Paul Norman penor...@mac.com: Subarea members are a pain and duplicate geographic information, +1, avoid them as they do not add something what would not already be said otherwise. cheers, Martin Subareas still seem to be used in a lot of countries, such as, those I ran into casually: USA: http://www.openstreetmap.org/relation/148838 France: http://www.openstreetmap.org/relation/2202162 Ukraine: http://www.openstreetmap.org/relation/60199 But checking other countries such as Germany, Switzerland and Haiti I can see that it is not there. I removed those subareas from the Nicaragua country relation and specified is_in=Nicaragua to the admin_level=4 relations. But, anyway this doesn't seem to have anything to do with the rendering. Is it right that this label rendering is happening only once in a while? Should we just wait, or is there something wrong with out data? Thank you! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre m...@delattre.de wrote: I was going over the departmentos (admin_level=4) in Nicaragua yesterday. And it does not explain to me why the names of them not getting rendered in Mapnik. Please compare: * Province (admin_level=4) in Costa Rica: http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051 (label Guanacaste) * Departamentos (admin_level=4) in Nicaragua http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no label Chontales) I noticed in OSM Inspector an error on the Chontales multipolygon: layer:ring_not_closed_hullrel_id:2194866 lastchange:2014-03-12T04:13:04Z errmsg:ring_not_closedarea:0.78 tags:admin_level=4 boundary=administrative name=Chontales Fix the errors to see if that fixes the rendering problem. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
Thank you, Clifford. I hope I could fix those, by rechecking all the tagging and roles (outer especially) in the relations. I think this could have been the reason. Nevertheless this phenonema of not rendering the label of the admin_level=4 regions is happening with all regions/departamentos in Nicaragua. Also the ones which are not throwing an error by the OSM Inspector [1] Please compare with the relations which are subareas of the county's relation [2]. I further added a label to one of the regions' relation [3], using the short name for testing purposes, and placed it where no much other stuff is around. Marking the tiles, close to this label node, as /dirty to refresh them, would not render the region's label... :( [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=-85.04810lat=12.23695zoom=8overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes [2] http://www.openstreetmap.org/relation/287666 [3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589 On 04/07/2014 11:14 AM, Clifford Snow wrote: On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre m...@delattre.de mailto:m...@delattre.de wrote: I was going over the departmentos (admin_level=4) in Nicaragua yesterday. And it does not explain to me why the names of them not getting rendered in Mapnik. Please compare: * Province (admin_level=4) in Costa Rica: http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051 (label Guanacaste) * Departamentos (admin_level=4) in Nicaragua http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no label Chontales) I noticed in OSM Inspector an error on the Chontales multipolygon: layer:ring_not_closed_hull rel_id: 2194866 lastchange: 2014-03-12T04:13:04Z errmsg: ring_not_closed area: 0.78 tags: admin_level=4 boundary=administrative name=Chontales Fix the errors to see if that fixes the rendering problem. Clifford -- @osm_seattle osm_seattle.snowandsnow.us http://osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
In the relation for Nicaragua (id=287666), there are objects with role subarea. For example, addition of subarea role for Chontales is redundant with Relation Chontales (id=2194866). I dont know if this would fix the problem, but you could remove the redundant subarea members from the Nicaragua relation. Developpers that know how relations are rendered could tell what is the impact of redundant references adding subarea elements to the main relation. Pierre De : Felix Delattre m...@delattre.de À : Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Lundi 7 avril 2014 20h42 Objet : Re: [OSM-talk] admin_level 4 rendering Thank you, Clifford. I hope I could fix those, by rechecking all the tagging and roles (outer especially) in the relations. I think this could have been the reason. Nevertheless this phenonema of not rendering the label of the admin_level=4 regions is happening with all regions/departamentos in Nicaragua. Also the ones which are not throwing an error by the OSM Inspector [1] Please compare with the relations which are subareas of the county's relation [2]. I further added a label to one of the regions' relation [3], using the short name for testing purposes, and placed it where no much other stuff is around. Marking the tiles, close to this label node, as /dirty to refresh them, would not render the region's label... :( [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=-85.04810lat=12.23695zoom=8overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes [2] http://www.openstreetmap.org/relation/287666 [3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589 On 04/07/2014 11:14 AM, Clifford Snow wrote: On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre m...@delattre.de wrote: I was going over the departmentos (admin_level=4) in Nicaragua yesterday. And it does not explain to me why the names of them not getting rendered in Mapnik. Please compare: * Province (admin_level=4) in Costa Rica: http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051 (label Guanacaste) * Departamentos (admin_level=4) in Nicaragua http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no label Chontales) I noticed in OSM Inspector an error on the Chontales multipolygon: layer:ring_not_closed_hull rel_id:2194866 lastchange:2014-03-12T04:13:04Z errmsg:ring_not_closed area:0.78 tags:admin_level=4 boundary=administrative name=Chontales Fix the errors to see if that fixes the rendering problem. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
I just added this today because in the local talk list (talk-ni) a friendly person pointed me to the relation defining Florida (http://www.openstreetmap.org/relation/162050) which is a subarea of USA http://www.openstreetmap.org/relation/148838 It made sense to me to add all the states/departamentos to the country's relation, so I did it. But this should be irrelevant to the rendering as the states of USA and the provinces of Costa Rica are getting rendered properly, no matter if they are as subarea defined in a parent relation (like it is the case in USA) or not (in Costa Rica). On 04/07/2014 01:29 PM, Pierre Béland wrote: In the relation for Nicaragua (id=287666), there are objects with role subarea. For example, addition of subarea role for Chontales is redundant with Relation Chontales (id=2194866). I dont know if this would fix the problem, but you could remove the redundant subarea members from the Nicaragua relation. Developpers that know how relations are rendered could tell what is the impact of redundant references adding subarea elements to the main relation. Pierre *De :* Felix Delattre m...@delattre.de *À :* *Cc :* Talk Openstreetmap talk@openstreetmap.org *Envoyé le :* Lundi 7 avril 2014 20h42 *Objet :* Re: [OSM-talk] admin_level 4 rendering Thank you, Clifford. I hope I could fix those, by rechecking all the tagging and roles (outer especially) in the relations. I think this could have been the reason. Nevertheless this phenonema of not rendering the label of the admin_level=4 regions is happening with all regions/departamentos in Nicaragua. Also the ones which are not throwing an error by the OSM Inspector [1] Please compare with the relations which are subareas of the county's relation [2]. I further added a label to one of the regions' relation [3], using the short name for testing purposes, and placed it where no much other stuff is around. Marking the tiles, close to this label node, as /dirty to refresh them, would not render the region's label... :( [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=-85.04810lat=12.23695zoom=8overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes [2] http://www.openstreetmap.org/relation/287666 http://www.openstreetmap.org/relation/287666 [3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589 On 04/07/2014 11:14 AM, Clifford Snow wrote: On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre m...@delattre.de mailto:m...@delattre.de wrote: I was going over the departmentos (admin_level=4) in Nicaragua yesterday. And it does not explain to me why the names of them not getting rendered in Mapnik. Please compare: * Province (admin_level=4) in Costa Rica: http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051 (label Guanacaste) * Departamentos (admin_level=4) in Nicaragua http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no label Chontales) I noticed in OSM Inspector an error on the Chontales multipolygon: layer: ring_not_closed_hull rel_id: 2194866 lastchange: 2014-03-12T04:13:04Z errmsg: ring_not_closed area:0.78 tags:admin_level=4 boundary=administrative name=Chontales Fix the errors to see if that fixes the rendering problem. Clifford -- @osm_seattle osm_seattle.snowandsnow.us http://osm_seattle.snowandsnow.us/ OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] admin_level 4 rendering
Subarea members are a pain and duplicate geographic information, but I dont think they cause any performance issues, largely because all the relevant tools ignore them. From: Pierre Béland [mailto:pierz...@yahoo.fr] Sent: Monday, April 07, 2014 12:29 PM To: Felix Delattre Cc: Talk Openstreetmap Subject: Re: [OSM-talk] admin_level 4 rendering In the relation for Nicaragua (id=287666), there are objects with role subarea. For example, addition of subarea role for Chontales is redundant with Relation Chontales (id=2194866). I dont know if this would fix the problem, but you could remove the redundant subarea members from the Nicaragua relation. Developpers that know how relations are rendered could tell what is the impact of redundant references adding subarea elements to the main relation. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
