[OSM-dev] New tool to convert from OSM to SHP

[Frederik Ramm]

Hi,

> I would strongly support the motion to implement this as an ogr2ogr
> module: it avoids duplication, is part of a framework, runs everywhere and
> is widely distributed and will thus have great potential of widening the
> user community of OSM data.

> There are modules that translate shapefiles into/from KML and doing a
> similar one for OSM XML should be not too difficult.

I don't know what exactly the KML converters do, and I'm not referring
to your post specifically, but many people talking about the subject
seem not to have a very clear picture of what shapefiles are.

1. About the OSM to Shapefile direction:

"Shapefile" is not something that is very well defined. People
sometimes talk as if it was just a matter of a "save as..." box in
your editor, just like you can save your document as .doc or .sdw. The
truth is more as if you were to talk about the conversion of OSM data
to (another form of) XML or CSV. It is not enough to specify the end
format, you will have to specify how many shapefiles you want and how
you want them structured.

One extreme would be generating three shapefiles - one for areas, one
for linear features, one for POIs. The file for linear features
would then have "database columns" named "type", "subtype", "user1",
... "usern" (you must specify the columns when creating the file),
and then you'd convert a secondary road as type=highway
subtype=secondary user1=Foo St etc. --- the other extreme would be
generating a myriad of shapefiles, for example one for every highway
type or so. The solution that works best on average is probably
something in the middle (for the shapefiles on download.geofabrik.de,
I generate one shapefile that contains all highway=... objects, with
additional columns for name etc.).

Ideally, the user should be able to configure which OSM objects he
wants in which shapefiles. Jochen's osmlib exporter allows you to do
very fine-grained selection (e.g. you could extract all oneway streets
into their own shapefile if need be, or everything that can be used by
cyclists). This comes at the price of the user having to write SOME
(very limited!) ruby code that sorts objects into appropriate
shapefiles - like this:

    if highway
        :roads << { :id => id, :name => name, :type => highway, :oneway => oneway }
    elsif waterway
        :waterways << { :id => id, :name => name, :type => waterway, :width => width }
    elsif railway
        :railways << { :id => id, :type => waterway }

If anyone manages to come even close to that flexibility and still
have a pretty GUI, that would really be an achievement. Maybe it is
possible using one of the usual Windows scripting languages. It is
equally hard for me to think about a simple way to define such a
complex conversion rule on an ogr2ogr command line, maybe one would
have to resort to a "rules file" there.
 
OSM to shapefile conversion is never lossless because you lose
topology, and you lose all those tags that you didn't prepare for in
your converter (no, you cannot generate a shapefile that has enough
columns to fit ALL possible tags in). 

2. About the Shapefile to OSM direction:

You don't have topology in Shapefiles. You might have two linear
objects in your "roads" shapefile, one ending at lat=48.99743335,
lon=8.712342222 and one ending at lat=48.997435582 lon=8.71233333. Is
there a junction? Do you generate *one* OSM node shared by both ways
(and where do you place it... or wait, maybe it's a tunnel after
all?), or do you stupidly create two OSM nodes, generating an OSM file
that has lots of duplicate nodes and no routing capabilities
whatsoever?

Shapefile to OSM conversion can only be successful if you have
detailed knowledge about the contents of the shapefile and can adapt
the conversion process accordingly. It works for specific cases (see
coastline import) but there's no general way of doing it without
a lot of extra "knowledge input".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'