On Fri, 2008-04-18 at 20:02 +0100, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Jon Burgess <[EMAIL PROTECTED]> wrote:
>
> > Provided we have the polygons describing the boundaries of countries,
> > states etc then we could tag the data during the osm2pgsql processing.
> > Alternatively it might be possible for Mapnik to query them at run time
> > (with the right join to a table containing boundary polygons in the data
> > source SELECT line it might even be possible today).
>
> I was thinking about that while I was walking home earlier. The
> main question I guess is how efficient PostGIS is at answering
> the question "which of these N hundred polygons is this data
> in", or how efficiently we can code the equivalent in osm2pgsql.
This is a valid concern. Having more than one table in the select seems
to confuse mapnik (possibly because it has trouble locating the correct
geometry column for the query).
I seem to be getting a reasonable result by adding a country column into
the DB after the import.
Importing the world_boundaries_m.shp polygon into postgis:
$ shp2pgsql -s 900913 -I -g border world_boundaries_m boundaries | psql -q gis
[ this srid is wrong, it should probably be 3365 but it is close enough
for this test and saves having to deal with transforming geometries ]
Then create a new table with data derived from the roads but with an
extra column added for the country:
gis=> create table c_roads as select
planet_osm_roads.*,boundaries.fips_cntry from planet_osm_roads,
boundaries where way && border and within(way, border);
SELECT
Time: 139292.756 ms
The above is for the UK subset of the planet and 2 minutes seems fairly
reasonable. The line table has about 6 times the data so would be much
slower. As long as the country specific rendering is restricted to
motorway/trunk/primary/secondary roads then the planet_osm_roads table
is all we need to process.
Then a quick test counting the number of roads per country:
gis=> select fips_cntry,count(*) as num from c_roads group by fips_cntry order
by num desc;
fips_cntry | num
------------+-------
UK | 74199
EI | 2582
FR | 703
IM | 199
(4 rows)
The above results seem reasonable given that this is against a UK planet
subset which includes small bits of France, Ireland etc.
It should then be possible to include fips_cntry as a filter in the
osm.xml.
We'll have to see whether this scales to cope with the whole planet file
and polygons for every county/state/province etc.
> > My main concern would be the maintainability of the osm.xml style file.
> > It is already nearing 200kB and adding country (or state) specific
> > rendering would make it even more complex.
>
> Indeed. I was thinking about that too, and I think it needs an
> extrat level of indirection, so the existing stylesheet stays
> largely as it is but instead of saying that a secondary road
> is rendered as #213455 or whatever some sort of code name is
> given and then that is mapped to the real colour based on the
> country.
I believe Artem proposed something similar to me once before but wanted
the feature code to be derived during the osm2pgsql import. This has the
benefit of making the rendering faster but it means that you have to
make the decision of how to categorise every feature at import time
which removes some flexibility from the osm.xml file (who knows, maybe
this is a good thing :-).
Jon
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
