Stefan Steiniger wrote: > Hi Landon,
> Am 08.07.13 11:30, schrieb Landon Blake: >> Stefan: >> You wrote: "Anybody an idea how to put all the tags?" >> You could "prescan" the OSM file to make a list of all the tags used in >> the file. Then create a feature schema with an attribute for each tag. >> You could even give the user a preview of the tags present in the OSM >> file, and let them chose which tags to import as attributes. (I can help >> you with the code for this if you want.) > mhm.. Not sure if there are simply too many tags in a file. Because OSM > has no unified and fixed tag set. But I found a webpage with some > standard ones. Will hopefully use that for some post-processing to find > obvious classes such as roads and building. GDAL has a pretty good OSM reader and I suggest at least to read the driver manual http://www.gdal.org/ogr/drv_osm.html > However, tag selection is an interesting idea but would require quite a > bit of extra work. Though, maybe for a second development stage it could > be done similar as michael did for the cvs reader? On the other hand, converting the free key/value pairs of OSM into fixed attribute schema is only a partial solution. More challenging and interesting exercise would be to think if the barriers of simple features and flat, fixed attribute schema could be broken somehow with OpenJUMP. The situation itself is not so complicated. We could have all the OSM geometries in one storage (call it as layer, table, you name it) which have only two attributes: the geometry and id of the feature. Then we would need another storage (layer, table...) for the OSM tags with three attributes: geometry_id, key/tag and value. Geometries should be joined with the tags by feature_id and join should allow one-to-many relation. Going from geometries into tags would happen be selecting a geometry, checking the id and catching the tags with the same feature_id. In opposite direction key/value table would be scanned first - find rows where key "place" has a value "city", pick up the feature_ids and select corresponding geometries. There would be many troubles, here are three first which came into my mind: - How to show the tags. Withour fixed schema the attribute table like we have in OpenJUMP would not work. I think that the useal way in OSM tools is to let user select one feature at a time and show the tags of the selected feature in a table. - How to seach from key/value table. For any bigger dataset there should be an index for all three fields feature_id, key, and value. And the geometry table should have a spatial index and a normal index for feature_id. - How to set rendering styles. The rules should be set according to key/value pairs but mastering how tags are used in OSM is not extremely easy task http://wiki.openstreetmap.org/wiki/Map_Features. Additional trouble is that actually also the geometry type of the feature should be checked because features with tags like "building=yes" can be either points or polygons Perhaps the geometry table should have third attribute "geometry_type" for fast and indexed searches. -Jukka Rahkonen- ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
