Re: [OSM-dev] Getting admin_level=* from relations to render properly
I've come to the conclusion that shared segments aren't stored how I was assuming, so the next best thing would be doing more pre-processing as Lennard suggested. While using a bot is A solution, but I don't think using a bot is the best solution, or even a good one. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
2010/4/28 Iván Sánchez Ortega : > This is less about thinking and more about doing. Believe it or not, the > first method that is able to solve the boundaries problem will win. No > matter if it's a bot, a osm2pgsql patch, or an ugly SQL query on the mapnik > stylesheet side of things. That's all hand waving and appeals to emotion and diverting attention away from fixing a problem. > And, personally, I think that a bot is the simplest, quickest way of > achieving this. I doubt this is the quickest or simplest, and certainly no where near the most efficient. Using a bot to brute force add information that can be derived from other bits of data is a waste of time, just like is_in=* tagging is just as useful for the same reasons. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28 April 2010 19:00, Lennard wrote: > That cannot be solved from mapnik. This is a job to be done during the db > import for mapnik, both for non-slim mode (a one off job) and slim mode > imports, which have to take into account loading diff files. At some point, > it just sounds much simpler to correctly tag the member ways. This is *not* > wrong, they *are* boundary demarcation lines. This can be solved in mapnik by using more selective query statements, currently there is limited or no limitation placed on the admin boundary queries... So yes this can be solved in mapnik/pgsql, however I lack the SQL knowledge to fix it, or this thread wouldn't have gone on for this long without a solution. As for pre-processing being more efficient, possibly, but you need to figure out the same sort of logic to figure it out in any case. > By the time mapnik sees the data, it has been processed. Relations could > have been converted into line geometries, and there is no way for mapnik to > discern those from the proper ways, other than the test for osm_id>0. I > suggest you play around with a limited dataset, and see how that ends up in > the pg db, in which tables, for different taggings. You are right about the osm_id, but I lack the ability to come up with a suitable query to do the test, which is why this thread is still going on. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
El 28/04/2010 10:13, John Smith escribió: > This is not the right way to do things, we need to fix the rendering > software to work properly, not use bots so software devs have a simple > way out. No, no, no. There is no point being an "architecture astronaut"[1] and making sure we've got the most perfect rendering system in the whole universe. [1] http://www.joelonsoftware.com/articles/fog18.html This is less about thinking and more about doing. Believe it or not, the first method that is able to solve the boundaries problem will win. No matter if it's a bot, a osm2pgsql patch, or an ugly SQL query on the mapnik stylesheet side of things. And, personally, I think that a bot is the simplest, quickest way of achieving this. Cheers, -- Iván Sánchez Ortega ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 10:58, Iván Sánchez Ortega wrote: >>> So you admit the logic can be problematic with the rendering, doesn't >>> that mean we're tagging incorrectly for renderers? >> >> Don't tag the member boundary ways, and you're right. > > So what? Area boundaries will be rendered twice, once per area. You'll > be back at the start :-/ I know, that wasn't my point. John argues boundary way tags shouldn't matter, when the way is a member of a boundary relations, and it should inherit some admin_level from those. He implies it's unnecessary tagging for the renderer. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 10:46, John Smith wrote: > They render as lines instead of areas, but they still render, I've > dealt with this issue a lot of time with broken postcodes in > Australia, fix the relation you fix the rendering... type=multipolygon boundary relations do not render. Just realised after sending my previous reply. The fix is easy, the result gobsmackingly ugly (read: overlapping lines). > That doesn't solve the issue, that just excludes information from > relations, we need to use relation information if the way information > doesn't exist, similar to the way information from relations work for > other objects. That cannot be solved from mapnik. This is a job to be done during the db import for mapnik, both for non-slim mode (a one off job) and slim mode imports, which have to take into account loading diff files. At some point, it just sounds much simpler to correctly tag the member ways. This is *not* wrong, they *are* boundary demarcation lines. > This is the order things need to be found, through a subselect or > join, after finding distinct segments, from those segments we need to > sort by way admin_level, and then by relation admin_level, simply > excluding information only glosses over the issue by excluding broken > multipolygons. By the time mapnik sees the data, it has been processed. Relations could have been converted into line geometries, and there is no way for mapnik to discern those from the proper ways, other than the test for osm_id>0. I suggest you play around with a limited dataset, and see how that ends up in the pg db, in which tables, for different taggings. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28 April 2010 18:49, Lennard wrote: > Looks fine. I can't look into the osm.org tile server db to see how it wound > (or didn't) up in there. Could be any of a number of reasons. You don't need to, although it would be great if the OSM tile server setup was better documented on how to put everything together, but that's an issue for another thread. However the style sheet is published to the SVN server: http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml > Don't tag the member boundary ways, and you're right. As someone else pointed out, you will get multiple overlapping ways being rendered which isn't the most ideal outcome. > There is no problem with rendering. The renderer just renders what is there, > which includes tagged member ways. The rendering software does 2 things, it takes a style sheet and applies that to data it uses, just because the software does what it's told doesn't mean it has been told to do the right thing. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
El 28/04/2010 10:49, Lennard escribió: >> So you admit the logic can be problematic with the rendering, doesn't >> that mean we're tagging incorrectly for renderers? > > Don't tag the member boundary ways, and you're right. So what? Area boundaries will be rendered twice, once per area. You'll be back at the start :-/ -- Iván Sánchez Ortega ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 9:27, John Smith wrote: > That makes no sense when rendering can derive it from relations to > pick the most important (lowest admin_level value) without people > needing to know which way is part of which relation. You are on the same train of thought I was on a year or so ago. > Ok, here's the way and here's the relation and here's the rendering, > please explain why it's not rendering the relation how ways nearby > render: Looks fine. I can't look into the osm.org tile server db to see how it wound (or didn't) up in there. Could be any of a number of reasons. > So you admit the logic can be problematic with the rendering, doesn't > that mean we're tagging incorrectly for renderers? Don't tag the member boundary ways, and you're right. > Ok so you admit there is a problem with rendering, but instead of There is no problem with rendering. The renderer just renders what is there, which includes tagged member ways. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28 April 2010 18:33, Lennard wrote: > No, if they were broken, they wouldn't render in the first place. They render as lines instead of areas, but they still render, I've dealt with this issue a lot of time with broken postcodes in Australia, fix the relation you fix the rendering... > Easy: slap a "where osm_id>0" on that query you posted, and only render > the (correctly tagged) ways. :) That doesn't solve the issue, that just excludes information from relations, we need to use relation information if the way information doesn't exist, similar to the way information from relations work for other objects. This is the order things need to be found, through a subselect or join, after finding distinct segments, from those segments we need to sort by way admin_level, and then by relation admin_level, simply excluding information only glosses over the issue by excluding broken multipolygons. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 10:17, John Smith wrote: > 2010/4/28 Iván Sánchez Ortega: >> "Ugly" gets short. The overlapping dashed lines just look horrible. >> >> http://www.openstreetmap.org/?lat=41.3067&lon=-3.1946&zoom=12 > > That usually occurs because of broken relational multipolygons... No, if they were broken, they wouldn't render in the first place. > However it's the same problem I'm trying to solve, limiting the number > of times the same shared segments get rendered. Easy: slap a "where osm_id>0" on that query you posted, and only render the (correctly tagged) ways. :) http://trac.openstreetmap.org/ticket/2094 -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
2010/4/28 Iván Sánchez Ortega : > "Ugly" gets short. The overlapping dashed lines just look horrible. > > http://www.openstreetmap.org/?lat=41.3067&lon=-3.1946&zoom=12 That usually occurs because of broken relational multipolygons... However it's the same problem I'm trying to solve, limiting the number of times the same shared segments get rendered. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
2010/4/28 Iván Sánchez Ortega : > I'd place my wages on a bot. Download the planet, check topology of > admin_level ways and relations, calculate the non-needed bits, upload > changes. So in other words instead of areas to figure out what is in the area we should just use a bot to tag each object with is_in=* tags? This is not the right way to do things, we need to fix the rendering software to work properly, not use bots so software devs have a simple way out. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
El 28/04/2010 9:27, John Smith escribió: > Ok, here's the way and here's the relation and here's the rendering, > please explain why it's not rendering the relation how ways nearby > render: > > http://www.openstreetmap.org/browse/way/32295414 > http://www.openstreetmap.org/browse/relation/80372 > http://osm.org/go/uTRwIeeW- Looks good to me. >> Where a tagged boundary way is part of n boundary relations, you >> will see n+1 overlapping lines in the render. IMO this is ugly, and >> you get no sense of the actual admin levels involved. "Ugly" gets short. The overlapping dashed lines just look horrible. http://www.openstreetmap.org/?lat=41.3067&lon=-3.1946&zoom=12 > That may be what's happening, in which case that's pointing out > where we need to look, we should structure the SQL query to return > only one way, with the highest admin_level. I don't think so. I'd place my wages on a bot. Download the planet, check topology of admin_level ways and relations, calculate the non-needed bits, upload changes. Cheers, -- Iván Sánchez Ortega ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
I think the problem with mapnik is this query: select way,admin_level from planet_osm_roads where "boundary"='administrative' it just select all ways and doesn't try to limit the returned information to distinct ways or order the results at all, and I'm not familiar enough with pgSQL to fix it, if it was MySQL you can tell it to group by the column you want distinct results for, but I think I need subselects or joins to do the same thing in pgSQL... Although you'd probably need to go a step further and order by way and then relation, not just admin_level... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28 April 2010 17:00, Lennard wrote: > How did this occur to you? Tagging the ways is even explicitly > documented on the wiki. That makes no sense when rendering can derive it from relations to pick the most important (lowest admin_level value) without people needing to know which way is part of which relation. > If the relation forms a closed loop, and is tagged as a boundary, it > should currently render. Ok, here's the way and here's the relation and here's the rendering, please explain why it's not rendering the relation how ways nearby render: http://www.openstreetmap.org/browse/way/32295414 http://www.openstreetmap.org/browse/relation/80372 http://osm.org/go/uTRwIeeW- > Should work currently. The major drawback to also drawing boundary > relations is that they can stack (in osm2pgsql+mapnik). Where a tagged > boundary way is part of n boundary relations, you will see n+1 > overlapping lines in the render. IMO this is ugly, and you get no sense > of the actual admin levels involved. That may be what's happening, in which case that's pointing out where we need to look, we should structure the SQL query to return only one way, with the highest admin_level. > Rendering just the boundary way makes for a clean border render, with a > predictable appearance. To this end, the wiki documentation describes > tagging the way with the highest order (lowest value) of admin_level. As > far as I'm aware, ti...@home already take this approach, and does not > render boundary relations. So you admit the logic can be problematic with the rendering, doesn't that mean we're tagging incorrectly for renderers? > I trust people will now bring the "don't tag for the renderer" mantra How'd ya guess? :) > into play, but in my mind, a boundary relation(*) describes the polygon, > so the administrative *area*, and the ways describe the demarcation > between administrative areas. Thus, it's the ways that should appear on > the rendered map, not the area. Ok so you admit there is a problem with rendering, but instead of fixing broken rendering software you suggest we do a lot of manual work to over come the short falls in the software, this imho is the wrong way to go, so my original question still stands, but you have pointed out where I should be looking to fix the problem properly. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 8:28, John Smith wrote: > It occurred to me a few weeks ago that ways shouldn't be tagged with > the admin_level, but instead use the information from relations, but How did this occur to you? Tagging the ways is even explicitly documented on the wiki. > this doesn't work, in fact I removed the admin_level tag from a way > that makes up part of a state border assuming the information would be > used from the relation instead, but it just didn't render at all until > I reinstate the admin_level on the way. If the relation forms a closed loop, and is tagged as a boundary, it should currently render. > I haven't figured out what needs to be fixed in the mapnik style sheet > to fix this, can anyone tell me what needs tweaking to fix this? Should work currently. The major drawback to also drawing boundary relations is that they can stack (in osm2pgsql+mapnik). Where a tagged boundary way is part of n boundary relations, you will see n+1 overlapping lines in the render. IMO this is ugly, and you get no sense of the actual admin levels involved. Rendering just the boundary way makes for a clean border render, with a predictable appearance. To this end, the wiki documentation describes tagging the way with the highest order (lowest value) of admin_level. As far as I'm aware, ti...@home already take this approach, and does not render boundary relations. I trust people will now bring the "don't tag for the renderer" mantra into play, but in my mind, a boundary relation(*) describes the polygon, so the administrative *area*, and the ways describe the demarcation between administrative areas. Thus, it's the ways that should appear on the rendered map, not the area. *) Actually tagged as a multipolygon, because, hey, that's what it really is. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Getting admin_level=* from relations to render properly
It occurred to me a few weeks ago that ways shouldn't be tagged with the admin_level, but instead use the information from relations, but this doesn't work, in fact I removed the admin_level tag from a way that makes up part of a state border assuming the information would be used from the relation instead, but it just didn't render at all until I reinstate the admin_level on the way. I haven't figured out what needs to be fixed in the mapnik style sheet to fix this, can anyone tell me what needs tweaking to fix this? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
