[OSM-talk] LV region border import

Greg Troxel gdt at ir.bbn.com
Sun May 31 17:54:51 BST 2009


  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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090531/d4d94088/attachment.pgp>


More information about the talk mailing list