Re: [OSM-dev] osm2pgsql slow on update import

2011-04-28 Thread Sven Geggus
Markus Wagner mar...@mwagner.info wrote: After vacuuming and fiddling with those values I am much closer to realtime. Currently at approx ~120% of realtime. So I think, there is hope, once I get faster disks. I'm reopening this thread because I have a very simular Problem and I suspect that

Re: [OSM-dev] XAPI and other solutions

2011-04-28 Thread Pierre-Alain Dorange
Serge Wroclawski emac...@gmail.com wrote: Yes, but they are huge... My original place=* for france is 50 MB (not compressed). 50 meg doesn't seem so big. Yes 50MB is fine. 2 GB (compressed) is huge. France extract if 2 GB compressed, i don't think my python script was able to handle

Re: [OSM-dev] XAPI and other solutions

2011-04-28 Thread Oliver Tonnhofer
On 28.04.2011, at 13:57, Pierre-Alain Dorange wrote: What kind of processing were you doing? I'm assuming some kind of XML (unless you were using the protobuffs). If thats the case, you can use a simple SAX parser. If you need an example, I'll send you one. Yes i preprocess XML to extract

Re: [OSM-dev] XAPI and other solutions

2011-04-28 Thread Oliver Tonnhofer
On 28.04.2011, at 14:46, Serge Wroclawski wrote: On Thu, Apr 28, 2011 at 8:30 AM, Oliver Tonnhofer o...@omniscale.de wrote: If you are using Python, you should use iterparse from the ElementTree API, it is much nicer and faster. Faster than SAX? I'm not so sure. SAX calls the C

Re: [OSM-dev] XAPI and other solutions

2011-04-28 Thread Oliver Tonnhofer
On 28.04.2011, at 16:00, Martijn van Exel wrote: Interesting, this totally uproots my firm conviction that SAX parsing is always more time- and memory-efficient than tree/DOM-based parsing. Sure. DOM based parser need to keep the whole tree in memory which doesn't work well with large XML

Re: [OSM-dev] XAPI and other solutions

2011-04-28 Thread Peter Körner
Am 28.04.2011 16:11, schrieb Oliver Tonnhofer: On 28.04.2011, at 16:00, Martijn van Exel wrote: Interesting, this totally uproots my firm conviction that SAX parsing is always more time- and memory-efficient than tree/DOM-based parsing. From my experience the expat-sax immplementation is

Re: [josm-dev] Which seperator is used for keyborad shortcuts in wiki/josm-jar

2011-04-28 Thread colliar
Am 26.04.2011 16:35, schrieb Dirk Stöcker: On Tue, 26 Apr 2011, colliar wrote: I have found different seperators for keyboard shortcuts in JOSM. * On the wiki pages mainly - is used. * In JOSM menus a wild mixture of + and - is used. In the menus is no wild mixture, but: * control-keys

[josm-dev] How to present results of my conflation analysis

2011-04-28 Thread Josh Doe
I've implemented the algorithmic part of a conflation tool in a JOSM plugin, pretty much following what I wrote down here: http://wiki.openstreetmap.org/wiki/Conflation/Nodes Right now I'm just using the Euclidean distance in the cost function, but we can of course add other costs like

Re: [josm-dev] How to present results of my conflation analysis

2011-04-28 Thread Dirk Stöcker
On Thu, 28 Apr 2011, Josh Doe wrote: Any ideas would be much appreciated! A long term plan is to use the mapview also to view subsets of the map. So we could have e.g. a dialog with two small sections, each showing a partial map. One map shows the old state, one map the new state. This