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.
_
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
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 t
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 mos
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
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 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 ever
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
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.
> O
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:
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 b
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
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
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
>
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, i
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
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
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
18 matches
Mail list logo