[OSM-dev] Topologicial correctness in OSM

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Wed Jan 17 19:26:49 GMT 2007

Nick Black wrote:
>Sent: 17 January 2007 6:59 PM
>To: Jon Burgess
>Cc: dev at openstreetmap.org
>Subject: Re: [OSM-dev] Topologicial correctness in OSM
>Hurray  I was just about to start writing a script to do it.  I've
>said it before, utils/ is a goldmine.  Can you believe that Mapnifo
>TABs do not support topology?  I had naively assumed they would. +1
>for OSM

I'd be really interested to know (for my own education more than anything
else) how many generic systems and formats for geodata treat it like CAD (ie
layers of lines with no physical connection between the layers) and how many
are more like OSM where any concept of layers is applied as attributes to
the data itself.

Answers direct to me if you prefer not to clog the list.



>On 1/17/07, Jon Burgess <jburgess777 at googlemail.com> wrote:
>> On Wed, 2007-01-17 at 17:19 +0000, Nick Black wrote:
>> > Hello,
>> >
>> > Whilst trying to produce .osm from the brazillian TABs, I've run into
>> > a problem, in that the output I can produce output in OSM XML, but it
>> > is topologically incorrect, as it duplicates nodes at intersections.
>> > My process is:
>> >
>> > TAB > Import to PostGIS usign ogr2ogr > Script to talk to PG, and
>> > input data to OSM MYSQL via dao.rb .
>> >
>> > One solution to the problem is to go through mysql and compare each
>> > lat and lon value to each other, identifying the duplicate nodes and
>> > then deleting one set and correcting their parent segment - this seems
>> > a rediculous way to do it though.
>> > Does anyone have a better idea how to go about it?  I cant see how
>> > PostGIS maintains topology, but it obviously does somehow.
>> >
>> It is fairly ridiculous but works. If you can get the data into an OSM
>> style XML file then the script in utils/simplify/simplify.pl will do
>> this for you. Specify a fairly small minimum feature size e.g.
>> --simplify=0.00001 which should get rid of any nodes within about 1m of
>> each other.
>> The script is quite memory hungry on larger data sets. If this is an
>> issue then I may be able to provide a C implementation at some time in
>> the future.
>>         Jon
>Nick Black
>dev mailing list
>dev at openstreetmap.org

More information about the dev mailing list