John Smith wrote: > This is already dealt with for coast lines, so it shouldn't be much of > a jump to deal with country borders in a similar way.
Indeed, but a factor to take into account. Only update your internal version of the boundary when a newer and valid version is in OSM. > At present we're using multiple relations where the name changes along > a route but the ref stays the same and vice versa so it's not possible > with the current pre-processing that is done to do a nice little query > to get the shield and name from the same query. I have no idea how to > fix this. If those relations get flattened into a planet_osm_line geometry, you have 2 (or more?) for the same stretch of road. One for the shields, another for the name. Join them up in a query, or split shields and names handling everywhere and take what you need from the relevant geometries. > The other biggy is dealing with the country borders during > pre-processing, again no idea how to do this. You'd have to supply osm2pgsql with the relevant borders right off the bat, before it starts importing. That would mean 2 runs over the planet file (ouch!), or publishing a separate file with the relevant data. That is if you let osm2pgsql do the processing. As with coastlines, the country/state boundaries don't change drastically in the course of weeks, so an updated version of the regions could be generated every once in a while. OTOH, if osm2pgsql will only run some queries and let postgis handle the stamping of features with a proper field to filter on in the stylesheet, it can be done at the end of the import. The challenge to this method is in how to handle diffs. You wouldn't want to run through every geometry in your database everytime you import diffs, but only the changed ones. One more issue I see is what to do with features that cross these boundaries? Which style will/should they get? Should the import split them into 2 features, each on one side of the boundary? -- Lennard _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
