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
On 28 April 2010 17:00, Lennard l...@xs4all.nl 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
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
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
2010/4/28 Iván Sánchez Ortega i...@sanchezortega.es:
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
2010/4/28 Iván Sánchez Ortega i...@sanchezortega.es:
Ugly gets short. The overlapping dashed lines just look horrible.
http://www.openstreetmap.org/?lat=41.3067lon=-3.1946zoom=12
That usually occurs because of broken relational multipolygons...
However it's the same problem I'm trying to
On 28 April 2010 18:33, Lennard l...@xs4all.nl 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
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,
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
On 28 April 2010 18:49, Lennard l...@xs4all.nl 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
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
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.
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
On 28 April 2010 19:00, Lennard l...@xs4all.nl 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
2010/4/28 Iván Sánchez Ortega i...@sanchezortega.es:
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
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.
16 matches
Mail list logo
