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.).
Keep it simple, one shapefile for each feature type would be most
effective. With the advent of new tagging schemes and classes, any tool
will always have to run behind to keep uptodate with the changing
tagging scheme.
Also, areas are not defined explicitely in the OSM format, but rather
implied implicitely through the tagging scheme. So you need to have an
understanding if certain tags mean that there is an area, or it simply
is a line. This adds another layer of complexity when it come to file
conversion.
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).
Again keep it simple, and to keep up with the tagging scheme, you could
do the following:
Create a shape file with all line features, record in the associated dbf
table the OSMID, User, time created/modified. Create a separate table
with all of the tags in triplets of OSMID,key,value. This way you have a
nice almost normalised data scheme. The shapefile is lean and fast to
load and process in any application (GIS?) that you might want, and you
can then link back the tags you are interested in through a relation on
the OSMID.
Again, a compromise might be to directly put the 10 most used tags
(name, highway, ...) as separate columns in the shape dbf for
convenience sake.
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".
Yes thats why I think if any converter would keep the process as generic
as possible, there are other tools then to do the custom bit.
begin:vcard
fn:Patrick Weber
n:Weber;Patrick
org:University College London
adr:;;Gower Street;London;;WC1E 6BT;United Kingdom
email;internet:[EMAIL PROTECTED]
title:Engineering Doctorate Student
tel;work:02077185430
url:http://www.ucl.ac.uk/cemi
version:2.1
end:vcard
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
