Hi Jukka, sorry for my late response. Yep.. you realized all the troubles that come with this new flexible format. As you will see, I basically decided to make it fit/flat with OJs inflexible model by displaying some key tags and merging the non-standard tags into one text field. A side effect is that I probably have lots of stuff (objects) twice in there and other stuff (objects) are missing (in particular as I am reading only one file so that information from neighbouring "file-tiles"/regions is not accounted for to build large relation objects - e.g. lakes). Probably one could keep all the infos for later for working with many files and for writing stuff back? or just get a osm file with larger extent ;)
However, after having seen the new iD editor I am not sure it makes sense to use OJ as OSM editor (i.e. it would be a lot of effort: weeks...months?). Also QGIS folks had a similar discussion and I think they opted for read-only now. Anyway, I hope you will soonish see what the flat output looks like - well, I also can send a pre-release jar. uhm.. maybe one more question to Ede: How can I write processing infos to OJs output window? This may be useful as a lot of stuff (i.e. nodes that make up ways and later polygons) is not found or geometries are invalid and therefore deleted. cheers, stefan Am 17.07.13 17:26, schrieb Rahkonen Jukka: > > 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 > ------------------------------------------------------------------------------ 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
