Re: [OSM-talk] Boundary rendering bug
On Thu, Feb 10, 2011 at 4:48 AM, Lennard l...@xs4all.nl wrote: The *way* renders z9-z11. The *relation* renders z11+. Aha. It all becomes clear. It still seems a little odd that a way without any admin_level tag is rendered before an admin_level=6 way/boundary though. I would personally prefer counties to be rendered at z9. Around here it would probably even work at 8 but I'm guessing that would cause problems in other parts of the world. But I should probably just be quiet about rendering styles, at least until I've actually played with mapnik a bit. I really don't know what I'm talking about :) At least I know what is going on in this situation now. Thanks, Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
It's not really a bug, if you have the following setup: [...] What you're telling mapnik is that there are two boundaries, one is admin_level 6, the other is admin_level undefined. The admin 6 one will render at z11 or closer, the undefined one renders at z9 to z11. Correct. And at z11 only, both are rendered, leading to a more solid line appearance. To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Uh, no. Please, do add boundary=administrative + admin_level=n. Where n is the highest order admin level that applies, so if two relations with admin_level=6 and 8 respectively use that way, set admin_level=6 on the way. And, I hate to say it, read the wiki. One of these days, I should just modify the mapnik stylesheet to use osmarender's boundary handling (render boundary lines from ways alone), and use the relations only for the name rendering. Bye bye overlapping* boundary rendering! * Which would bring so much goodness, that I wonder why I haven't done that yet. :) Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage Right, so why even bother with type=boundary when type=multipolygon will do fine? :) -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Apparently I failed to communicate clearly in my first email. Let's try this again. Daniel was right, though. Mapnik doesn't see that data as ways and relations. Both ways and relations are represented as lines in its db. Relations are 'flattened' during an import with osm2pgsql, and mapnik handles both of them exactly equal. Boundary relations tagged with admin_level=6 and member ways WITHOUT admin_level tags are rendered starting at z9 The *way* renders z9-z11. The *relation* renders z11+. Boundary relations tagged with admin_level=6 *and* member ways WITH admin_level=6 aren't rendered until z11 Both the *way* and the *relation* render z11+. Aren't overlapping* boundary renderings fun? :( * See my previous reply. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Uh, no. Please, do add boundary=administrative + admin_level=n. Where n is the highest order admin level that applies, so if two relations with admin_level=6 and 8 respectively use that way, set admin_level=6 on the way. And, I hate to say it, read the wiki. One of these days, I should just modify the mapnik stylesheet to use osmarender's boundary handling (render boundary lines from ways alone), and use the relations only for the name rendering. Bye bye overlapping* boundary rendering! * Which would bring so much goodness, that I wonder why I haven't done that yet. :) Why would this be needed? I don't see anything in the wiki that says boundary relations are treated differently than multipolygons. If you tag them twice (way and relation) your just going to render an extra overlapping way. You are definitely not supposed to duplicate tags on the outer ways of multipolygons (anymore). I will give you that I see where the wiki says it, that doesn't make it right in a technical sense though ;). Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage Right, so why even bother with type=boundary when type=multipolygon will do fine? :) I do believe this came up on the talk page at some point :). type=boundary has some more roles (that nothing supports yet, but they're a nice idea). I don't know of anything that doesn't treat them as synonyms. - Daniel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Why would this be needed? I don't see anything in the wiki that says boundary relations are treated differently than multipolygons. If you tag them twice (way and relation) your just going to render an extra overlapping way. You are definitely not supposed to duplicate tags on the outer ways of multipolygons (anymore). Right, so by stopping the rendering of boundary lines based on the relations, that rendering issue is gone. Osmarender has never done any differently. The relations are not useless. Their name, for instance, is very useful. So is their admin_level, to decide when, where, and how to show that name. That doesn't mean tagged ways are useless and their tags stripped. They do have a place in the scheme of things. I will give you that I see where the wiki says it, that doesn't make it right in a technical sense though ;). Many things in OSM don't exactly make technical sense, yet we still use them. :) Right, so why even bother with type=boundary when type=multipolygon will do fine? :) I do believe this came up on the talk page at some point :). type=boundary has some more roles (that nothing supports yet, but they're a nice idea). I don't know of anything that doesn't treat them as synonyms. Oh, the discussion has been going on and off for years now. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Hi, On 02/10/11 12:34, Daniel Sabo wrote: Why would this be needed? I don't see anything in the wiki that says boundary relations are treated differently than multipolygons. If you tag them twice (way and relation) your just going to render an extra overlapping way. You are definitely not supposed to duplicate tags on the outer ways of multipolygons (anymore). It has always been my thinking that type=boundary is obsolete and should be replaced by type=multipolgon, or at the very least, no distinction should be made between the two when rendering (thinking that both of them will sooner or later be supersed by the area data type). Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Toby Murray-2 wrote: It strikes me as odd that a tag on a member way affects the rendering of a relation in this way. Am I missing something? The same thing happens when a highway=* railway=abandoned way is part of a railway=abandoned relation. Remove the railway=abandoned from the way and it renders properly. Keep the railway=abandoned on and it renders like a highway at layer infinity. -- View this message in context: http://gis.638310.n2.nabble.com/Boundary-rendering-bug-tp6006610p6007418.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
This is probably a holdover from old style multipolygons that were defined by the tags on the outer ways and had no tags on the relations. But putting tags on both the way and the relation would be wrong anyways, because the renderer can't know that boundary on the way is the same boundary on the relation. If your going to use boundary relations don't put any of the boundary tags on the member ways, let the importer apply them if the renderer needs it. - Daniel On Feb 8, 2011, at 10:33 PM, Toby Murray wrote: I think I have identified a Mapnik style bug in boundary rendering but since I am not very familiar with rendering rules I thought I would make sure other people think it is a bug before I submit a ticket about it. A few days ago I reworked the county boundaries in Colorado and then tonight in Wyoming. In Colorado I stripped all the tags off of the ways except for boundary=administrative and put them all into boundary relations. After this change, someone I know in Colorado complained that the county borders stopped rendering in osmarender. When I mentioned this on IRC it was suggested to leave admin_level=6 on the ways as well as in the relations. Kind of tagging for the renderer I suppose... but I've seen worse :) Anyway, I tried this in Wyoming tonight. Turns out this has an adverse effect on Mapnik rendering. Ways that only have boundary=administrative and are members of a boundary relation with admin_level=6 in the relation are rendered starting at z9. However if the way has admin_level=6 on it, while still being in an identical relation, then mapnik doesn't start rendering the boundary until z11. It strikes me as odd that a tag on a member way affects the rendering of a relation in this way. Am I missing something? You can see the effect here: http://www.openstreetmap.org/?lat=41.326lon=-107.747zoom=9layers=M You can see this county border being rendered heading south into Colorado: http://www.openstreetmap.org/browse/way/98395444 There is a county border just to the west going north into Wyoming that is not rendered: http://www.openstreetmap.org/browse/way/98838375 Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
2011/2/9 Daniel Sabo daniels...@gmail.com: This is probably a holdover from old style multipolygons that were defined by the tags on the outer ways and had no tags on the relations. But putting tags on both the way and the relation would be wrong anyways, because the renderer can't know that boundary on the way is the same boundary on the relation. This depends on the situation. Say you are mapping a public square with a (separately as an area mapped) monument in the middle. Obviously you would need a multipolygon relation, because the highway-area should not cover the monument. But the name of the square should IMHO remain on the way, because the whole square has this name, including the monument. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
2011/2/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: This depends on the situation. Say you are mapping a public square with a (separately as an area mapped) monument in the middle. Obviously you would need a multipolygon relation, because the highway-area should not cover the monument. But the name of the square should IMHO remain on the way, because the whole square has this name, including the monument. but I agree, you will have to set area=yes as well on the way, because otherwise the renderer can not know that the name is referring to an area and not to the way itself (because we don't have a dedicated polygon-entity in OSM, we simply add area=yes). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Agreed. What I mean is that if there are tags that apply to the multipolygon itself they should be only on the multipolygon. In your example the monument would be an inner way of the multipolygon and shouldn't have any tags related to the public square, but it would also be a monument, and the tags for the monument would belong on the monument's way. - Daniel On Feb 9, 2011, at 5:07 AM, M∡rtin Koppenhoefer wrote: 2011/2/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: This depends on the situation. Say you are mapping a public square with a (separately as an area mapped) monument in the middle. Obviously you would need a multipolygon relation, because the highway-area should not cover the monument. But the name of the square should IMHO remain on the way, because the whole square has this name, including the monument. but I agree, you will have to set area=yes as well on the way, because otherwise the renderer can not know that the name is referring to an area and not to the way itself (because we don't have a dedicated polygon-entity in OSM, we simply add area=yes). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
It's not really a bug, if you have the following setup: Member way: boundary = administrative Relation: boundary = administrative admin_level = 6 What you're telling mapnik is that there are two boundaries, one is admin_level 6, the other is admin_level undefined. The admin 6 one will render at z11 or closer, the undefined one renders at z9 to z11. To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Relation: boundary = administrative admin_level = 6 name = Something Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage - Daniel On Feb 9, 2011, at 11:27 AM, Toby Murray wrote: Well like I said, leaving the admin_level=6 on the ways is indeed tagging for the renderer. However isn't there still a mapnik bug here no matter how you look at it? Shouldn't an admin_level=6 boundary be rendered at the same zoom level whether it is mapped as a relation or as a way? Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
What you say makes perfect sense. But you got my situation wrong. When admin_level=6 *IS* specified on the way it doesn't render until z11. When it is only on the relation but NOT on the way then it renders at z9. Toby On Wed, Feb 9, 2011 at 8:08 PM, Daniel Sabo daniels...@gmail.com wrote: It's not really a bug, if you have the following setup: Member way: boundary = administrative Relation: boundary = administrative admin_level = 6 What you're telling mapnik is that there are two boundaries, one is admin_level 6, the other is admin_level undefined. The admin 6 one will render at z11 or closer, the undefined one renders at z9 to z11. To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Relation: boundary = administrative admin_level = 6 name = Something Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage - Daniel On Feb 9, 2011, at 11:27 AM, Toby Murray wrote: Well like I said, leaving the admin_level=6 on the ways is indeed tagging for the renderer. However isn't there still a mapnik bug here no matter how you look at it? Shouldn't an admin_level=6 boundary be rendered at the same zoom level whether it is mapped as a relation or as a way? Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Ah, I think I see what you're saying. What zoom level do you expect it to render at? The current stylesheet doesn't render county boundaries until z11, period. My reading of the stylesheet [1] is that by not specifying an admin level you're abusing the admin-other category and making it render at lower zoom. If you want counties to intentionally render at z9 good luck getting someone to change the style :P. I do agree that it would look nicer if it rendered them at lower zoom. - Daniel [1] http://svn.openstreetmap.org/applications/rendering/mapnik/inc/layer-admin.xml.inc On Feb 9, 2011, at 6:36 PM, Toby Murray wrote: What you say makes perfect sense. But you got my situation wrong. When admin_level=6 *IS* specified on the way it doesn't render until z11. When it is only on the relation but NOT on the way then it renders at z9. Toby On Wed, Feb 9, 2011 at 8:08 PM, Daniel Sabo daniels...@gmail.com wrote: It's not really a bug, if you have the following setup: Member way: boundary = administrative Relation: boundary = administrative admin_level = 6 What you're telling mapnik is that there are two boundaries, one is admin_level 6, the other is admin_level undefined. The admin 6 one will render at z11 or closer, the undefined one renders at z9 to z11. To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Relation: boundary = administrative admin_level = 6 name = Something Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage - Daniel On Feb 9, 2011, at 11:27 AM, Toby Murray wrote: Well like I said, leaving the admin_level=6 on the ways is indeed tagging for the renderer. However isn't there still a mapnik bug here no matter how you look at it? Shouldn't an admin_level=6 boundary be rendered at the same zoom level whether it is mapped as a relation or as a way? Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundary rendering bug
Apparently I failed to communicate clearly in my first email. Let's try this again. Boundary relations tagged with admin_level=6 and member ways WITHOUT admin_level tags are rendered starting at z9 Boundary relations tagged with admin_level=6 *and* member ways WITH admin_level=6 aren't rendered until z11 This seems like a discrepancy. You can see county borders being rendered at z9 in the link from my first email: http://www.openstreetmap.org/?lat=41.326lon=-107.747zoom=9layers=M Toby On Wed, Feb 9, 2011 at 9:43 PM, Daniel Sabo daniels...@gmail.com wrote: Ah, I think I see what you're saying. What zoom level do you expect it to render at? The current stylesheet doesn't render county boundaries until z11, period. My reading of the stylesheet [1] is that by not specifying an admin level you're abusing the admin-other category and making it render at lower zoom. If you want counties to intentionally render at z9 good luck getting someone to change the style :P. I do agree that it would look nicer if it rendered them at lower zoom. - Daniel [1] http://svn.openstreetmap.org/applications/rendering/mapnik/inc/layer-admin.xml.inc On Feb 9, 2011, at 6:36 PM, Toby Murray wrote: What you say makes perfect sense. But you got my situation wrong. When admin_level=6 *IS* specified on the way it doesn't render until z11. When it is only on the relation but NOT on the way then it renders at z9. Toby On Wed, Feb 9, 2011 at 8:08 PM, Daniel Sabo daniels...@gmail.com wrote: It's not really a bug, if you have the following setup: Member way: boundary = administrative Relation: boundary = administrative admin_level = 6 What you're telling mapnik is that there are two boundaries, one is admin_level 6, the other is admin_level undefined. The admin 6 one will render at z11 or closer, the undefined one renders at z9 to z11. To map the boundary as a relation you should have: Member way: no boundary tags (that includes the boundary name) Relation: boundary = administrative admin_level = 6 name = Something Boundary relations are just specialized multipolygons once they reach the renderer so all the rules here apply: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage - Daniel On Feb 9, 2011, at 11:27 AM, Toby Murray wrote: Well like I said, leaving the admin_level=6 on the ways is indeed tagging for the renderer. However isn't there still a mapnik bug here no matter how you look at it? Shouldn't an admin_level=6 boundary be rendered at the same zoom level whether it is mapped as a relation or as a way? Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Boundary rendering bug
I think I have identified a Mapnik style bug in boundary rendering but since I am not very familiar with rendering rules I thought I would make sure other people think it is a bug before I submit a ticket about it. A few days ago I reworked the county boundaries in Colorado and then tonight in Wyoming. In Colorado I stripped all the tags off of the ways except for boundary=administrative and put them all into boundary relations. After this change, someone I know in Colorado complained that the county borders stopped rendering in osmarender. When I mentioned this on IRC it was suggested to leave admin_level=6 on the ways as well as in the relations. Kind of tagging for the renderer I suppose... but I've seen worse :) Anyway, I tried this in Wyoming tonight. Turns out this has an adverse effect on Mapnik rendering. Ways that only have boundary=administrative and are members of a boundary relation with admin_level=6 in the relation are rendered starting at z9. However if the way has admin_level=6 on it, while still being in an identical relation, then mapnik doesn't start rendering the boundary until z11. It strikes me as odd that a tag on a member way affects the rendering of a relation in this way. Am I missing something? You can see the effect here: http://www.openstreetmap.org/?lat=41.326lon=-107.747zoom=9layers=M You can see this county border being rendered heading south into Colorado: http://www.openstreetmap.org/browse/way/98395444 There is a county border just to the west going north into Wyoming that is not rendered: http://www.openstreetmap.org/browse/way/98838375 Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
