On Mon, 2007-07-30 at 21:02 +0200, Stefan de Konink wrote: > On Mon, 30 Jul 2007, Marc Kessels wrote: > > > Anyhow: my program actually does this: you can specify a bounding box > > (in the source, could be a command line parameter, but "make 2AND" is > > just as simple for me....) and it will look at ways which have at least > > one point in this bounding box. The program will use much less memory in > > that case, of course. > > In case you make the bounding box as large as the Netherlands (or make > > the bouding box always return "-1") you do need to remember all nodes, > > and it will consume a lot of memory. > > I suppose you are suggesting to divide the complete country into several > > bounding boxes, and export per box. Am I right? > > Per segment a bounding box as big as -1 < n < 1 - segment. So not a > linear segmentation, it would suck on the boundaries of it. > > Get next segment from AND data > - Get previous, next segment > - Calculate boundingbox of 3 segments > - Fetch boundingbox OSM/Output > ? empty: merge > ? nonempty: > Join segments based on requirements X,Y,Z (name for example) > Levenstein distance tricks etc. > Other merge tricks. > > > This would require that you go through the AND data a multiple number of > > times, which would take quite long. Also you will have an issue with > > ways that extend through a multiple number of boxes. Of course you could > > write some logic to catch this (e.g. by using only the most top left > > coordinate of a way) and output each way only one time, but you still > > have an issue that you are most likely creating duplicates of nodes > > outside of the current box. (the way will be attached to another way in > > another box, for wich also a new nodeID will be created). This could be > > solved by looking through the already created OSM file, but than you > > again have a file-access, and I think it will then be as slow as > > swapping data from and to memory... > > There is nobody saying you should do this in one phase, instead of > specialistic reduce staps. (For example phase 1, check for duplicate...) > > > > Obviously, I did not need to go through this hassle, since my machine > > did have enough memory.... :) > > Sure, I don't want to sound hard because you made this in the first place, > which is a very good job. But I could consider this lazy programming and > bad design. Sure *it* works and it should probably only run one time, but > since people are now experimenting with it, it could have been designed > better reducing the memory requirements. Since this was no objective or > requirement for you we should not bother... > > > > Anyway my comments can always be dropped to the dustbin :) > >
comments are certainly welcome, patches even more! especially because I cannot follow your pseudo-code, but that can be because I am not a professional programmer. ;-) I can think of a number of improvements to create a better import than the current one, like one that is able to merge the data directly into the osm-database via the api, looking at already existing data, and deciding on all the available info whether a way is already in the osm-database, even taking into account inaccuracies in osm and AND data... However, the aim I had in mind, was that using this import module, one could convert a limited area to osm, read that with JOSM into one layer and download the existing data in another layer. (which is possible in the latest version of JOSM). For empty area's merging can be done quickly (and even automatically, I think). and for already mapped data it will be more (hand)work. My current priority however, is first fixing some loose ends: -duplicate nodes in AND data -area's having a node-id in AND data, -merging ways having the same tags (exluding branching ways) -put housenumbers in the data (conflicts with the previous) -... help is appriciated. Marc > > > Stefan > > > _______________________________________________ > dev mailing list > [EMAIL PROTECTED] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev _______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
