My main concern is should I import data as is or optimize this data as they are quite detailed? Also each region border is one separate polygon. Should I merge neighbour region nodes and import seperate border lines or again should I leave data as is?
While out riding just now I crossed a town line that I didn't see on my Etrex (which had cloudmade-converted osm data), and that got me thinking about the massgis town boundary shapefiles and what the best way to import them is; I suspect your problem is almost the same as mine. (Massachusetts is fully made of of city/towns that are mutually exclusive and jointly exhaustive - there are no "unincorporated areas" not in a town within the state. Cities and towns are the same thing From the border/GIS point of view, differing only in form of government. Boundaries are defined from acts of government long ago, but then also From monuments on the ground (which must be checked every 5 years by each town's governement) - so exactly what the boundaries are is fairly complicated.) For each city/town, there are one or more polygons, and similarly for counties (groups of towns) and the whole state. The datasets appear not to be 100% internally consistent, coming from sources of different ages, so e.g. the town boundaries along the NH border might not equal the MA/NH border data. With any luck the town dataset is internally consistent, in that A's border with B matches B's border with A exactly. The OSM approach seems to be not to have duplicate ways or nodes. So I think the thing to do is import all of this into some spatial database, and check for the coincidental nodes, and produce a set of ways where each way is a border of two towns running as far as possible before it diverges to different towns. Finally, make a relation for each town. For counties and the state border, I wonder if using those datasets as a guide and finding the town ways that are closest is best, essentially just building a relation from town boundary segments. If the Latvian data is internally consistent, then the above will be a bit easier. They might have the broken-down ways/relations available, even if they normally publish only datasets which are separate polygons for each region or city. As for "optimizing", I think an important goal of imports is to be able to take next year's improved data from the upstream provider and figure out what changes if any need to be made to bring OSM into alignment, differentiating between "upstream changed, and we didn't edit it" and "we edited it".
pgppyJHb1RYwy.pgp
Description: PGP signature
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk