> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p_weber.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080313/b4270617/attachment.vcf>