[OSM-dev] GPX import daemons, problems
Hi When trying to start the gpx_import daemons, and getting a load of errors in the log .. where to start? http://pastie.org/640454 What can I try here to get this working? Thanks Mikel ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX import daemons, problems
On 03/10/09 15:31, Mikel Maron wrote: When trying to start the gpx_import daemons, and getting a load of errors in the log .. where to start? http://pastie.org/640454 What can I try here to get this working? It looks like you're trying to start the old ruby version, which hasn't been used for a while now and probably hasn't been updated to work with postgres yet - it is complaining because the flag fields it is comparing are proper booleans in postgres so it needs to compare to false, not zero. The main site uses a C version of the importer now, which is in the repository somewhere. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
On Oct 2, 2009, at 9:16 AM, Radek Bartoň wrote: Hello everyone. First of all, I want to share with my two scripts for Mapnik rendering. First is a modified version of generate_tiles.py to use multithread rendering. Radek, Very interesting work! Jon recently added threading to generate_tiles.py in svn as well: http://trac.openstreetmap.org/changeset/17484 I would if you have compared your implementation yet? Second is a modified generate_image.py to generate large bitmap posters like [1,2]. It uses tiled rendering so it's possible to render very large areas with high DPI. Were you running into limitations within Mapnik or just memory when rendering large single images? Only limitation is that whole poster must fit into computer's memory during merging and texts drawing because I don't know any image rendering library which can draw to memory mapped files or such. See scripts' code and comments or ask for detailed information. Great, I'll enjoy taking a look at this. d Cheers, Dane ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] This #petition needs your votes: Vote for legal use of Google's aerial imagery for #OpenStreetMap tracing!
I have found this in the OpenStreetMap news, and I wondered why I have given the first vote for it. http://twitter.com/kalsch/status/4582749178 Please spread this! Andi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Jon recently added threading to generate_tiles.py in svn as well: Oh, I needed it two months ago so I wrote it. http://trac.openstreetmap.org/changeset/17484 I would if you have compared your implementation yet? Sorry, I don't understand the meaning of this sentence. Were you running into limitations within Mapnik or just memory when rendering large single images? When rendering large image for large geospatial area - whole Czech Republic. For example if you set x_parts and y_parts to 1 in the script and when you run it on 2GB RAM machine with 32-bit operating system. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Were you running into limitations within Mapnik or just memory when rendering large single images? Ah, now I remember, the memory error was caused by large memory needs when rendering hillshading layer in GeoTIFF file. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] This #petition needs your votes: Vote for legal use of Google's aerial imagery for #OpenStreetMap tracing!
Erm, its been all over the mailing lists about 2 weeks ago, it was featured on the OpenGeoData blog, it has 1,452 positive votes as I write this 2009/10/3 Andreas Kalsch andreaskal...@gmx.de: I have found this in the OpenStreetMap news, and I wondered why I have given the first vote for it. http://twitter.com/kalsch/status/4582749178 Please spread this! Andi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Thomas Wood (Edgemaster) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
On Oct 3, 2009, at 1:27 PM, Radek Bartoň wrote: Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Were you running into limitations within Mapnik or just memory when rendering large single images? Ah, now I remember, the memory error was caused by large memory needs when rendering hillshading layer in GeoTIFF file. Yes, I was thinking that might have been the issue. We have a fix for that now in Mapnik SVN trunk. Would be great to get your help testing: http://trac.mapnik.org/ticket/54 Dane ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
On Oct 3, 2009, at 1:24 PM, Radek Bartoň wrote: Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Jon recently added threading to generate_tiles.py in svn as well: Oh, I needed it two months ago so I wrote it. http://trac.openstreetmap.org/changeset/17484 I would if you have compared your implementation yet? Sorry, I don't understand the meaning of this sentence. I must have been asleep writing that sentence, sorry! I meant to ask if you had yet compared your generate_tiles.py threading support to the recent additions in svn? I assume not since you wrote yours, as you say several months ago, but it would be interesting to test the speed of each version. Dane ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] JOSM Tested
Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Freitag, 2. Oktober 2009 22:20 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested I wrote on Mon, 28 Sep 2009, please do not develop or checkin new stuff in next time so code can mature a bit (but do bugfixes instead :-). If no larger bugs show inbetween I would say the next tested version should be released next weekend. Ok, we had some critical bugs fixed this weekend, so I think the timeline should be expanded a bit to verify if fixes are correct. So expect next tested somewhen mid or end of next week. Are there any critical things left? I think no, but if you think so, then tell the bug report number. and now I have a problem. We had critical bug-fixes again which means another delay. But also if we continue this we wont get a tested at all, so I ask you all - Should a new tested be released sunday evening? Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
I would preffer to have new tested released asap, the best would be releasing #2221 right now :-). I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. On Sat, Oct 3, 2009 at 11:34 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Ok, ok, my fault. I really thought this feature to be uncritical and worth to be in tested. We can make #2221 tested nevertheless if nobody sees troublesome bugs in it. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. Great! Hopefully, this will make BackreferenceDataSet and CollectBackReferencesVisitor obsolete. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Jiri Klement Gesendet: Samstag, 3. Oktober 2009 11:48 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested I would preffer to have new tested released asap, the best would be releasing #2221 right now :-). I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. On Sat, Oct 3, 2009 at 11:34 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Ok, ok, my fault. I really thought this feature to be uncritical and worth to be in tested. We can make #2221 tested nevertheless if nobody sees troublesome bugs in it. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
On Sat, 3 Oct 2009, Jiri Klement wrote: I would preffer to have new tested released asap, the best would be releasing #2221 right now :-). I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. Well, that is independent. You can start in any case, as tested phase means also slow development, so your code wont get out of sync even if you can't check it in). The problem is: when I do a tested with major bugs, then we need to start with bugfix releases and this is somehing I want to prevent because it is much additional work. So start your development with assumption in mind that 2221 will get tested on sunday. :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Fixed this one. Thought it was a bug in the MultiSplit code which I though has been tested otherwhere. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
works for me, too, thanks! -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Samstag, 3. Oktober 2009 12:22 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Fixed this one. Thought it was a bug in the MultiSplit code which I though has been tested otherwhere. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
Henrik Niehaus wrote: Ray Foulkes schrieb: Hi Jan, thankyou, I do not know what I was doing wrong the first time around. I did as you suggested and created a java project using the sources in core - it all worked and runs the main program OK. I can navigate the Java e.g. find declarations, references and run the main application. etc. BUT, I was trying to debug plugins... When I tried to do the same thing after downloading http://svn.openstreetmap.org/applications/editors/josm/ (which includes all the plugins) and added the directory josm as a project, there are many errors including some Java errors in the plugins which are Eclipse internal errors. Also, I then cannot run the core application. I think it is because of the directory in which the application is started does not contain all the necessary files. I do not know how to tell Eclipse to default the startup directory to another directory. My problem is that I am trying to learn Eclipse at the same time as learning the code of Josm. I discovered that I can add plugins individually i.e. create a new project and link it to core and at least compile the plugin even if I cannot run it. Anyway, thankyou for your response. I have at least been able to start investigating the codes of JOSM. Ray Jan Peter Stotz wrote: Ray Foulkes schrieb: If I use an svn client to download to a directory then point Eclipse to construct a java project itself, there are hundreds of Java errors which I have not fully investigated but look nasty. Not surprising since the build scripts I don't think are being used in that case. The Eclipse relevant part of JOSM is the core directory. Check-out the path you mentioned outside of Eclipse and then add the core directory as Project with external sources into Eclipse. This should work for JOSM itself. Plugins are a different matter. Jan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev Hi Ray, I did some screen captures some time ago for another user who wanted to get in touch with josm development. Have a look at these two videos (both divx in avi, no sound): http://hampelratte.org/zeugs/checkout_josm.avi http://hampelratte.org/zeugs/checkout_openstreetbugs.avi Cheers, Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev Thanks Henrik, those videos look very comprehensive. I will patiently follow them. Unfortunately I have to stop working today because I am to travel from France to Glasgow by car(hopefully with JOSM+livegps+surveyor on my eeepc running Ubuntu netbook remix). The reason for my interest in the development is that that combination gives many errors of bug #2480, (duplicates #2725 #3238 #3457#1662) if I leave the viewing pane open, which I would like to have a go at fixing. Thankyou very much for responding to my request, Ray ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
On Sat, 3 Oct 2009, Ray Foulkes wrote: Thanks Henrik, those videos look very comprehensive. I will patiently follow them. Unfortunately I have to stop working today because I am to travel from France to Glasgow by car(hopefully with JOSM+livegps+surveyor on my eeepc running Ubuntu netbook remix). The reason for my interest in the development is that that combination gives many errors of bug #2480, (duplicates #2725 #3238 #3457#1662) if I leave the viewing pane open, which I would like to have a go at fixing. Thankyou very much for responding to my request, Ray The reason is easy - Make the data access thread safe. I think there are sync keywords in Java to do so, but I do not really understand Java multithreading completely (I'm more a C/C++ guy :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
On Sun, Sep 27, 2009 at 10:04 PM, Dirk Stöcker openstreet...@dstoecker.de wrote: Are there any critical things left? I think no, but if you think so, then tell the bug report number. Perhaps this qualifies: http://josm.openstreetmap.de/ticket/3644 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Problem with referrers
Hi, I'm working on support for referrers and I run into a problem which I'm not sure how to fix. Currently JOSM quite often makes copies of primitive (using for example cloneFrom or special constructors). It's not obvious whether the copy is added to the dataset or is kept in case we need to get back to old version of primitive (for example Command.cloneMap). That's a bit problem because I don't want to have such copy in referrers list, I want only primitives that are really used in an dataset. To workaround this issues I'm thinking about introducing new classes - PrimitivePrototype, NodePrototype, WayPrototype and RelationPrototype. These classes will hold informations for one primitive, but it will not be possible to add these objects to the dataset. That will allow to clearly distinguish what's real primitive and whats just an backup copy for for example Command.cloneMap or Main.pasteBuffer. Obviously it will be possible to construct new primitive based on prototype. Method cloneFrom() and constructoctors like Node(Node n) will be removed to make sure everybody is using new system. This will also fix another issue - for some features (most notably reliable events when primitive is modified) I need for every primitive to be part of exactly one dataset. This can be forced by making all primitive constructors protected and allowing to create new primitives only using methods like Dateset.addNode(node parameters..) or Dataset.addNode(NodePrototype). What do you think about that? Can you think of any problems this might bring us? -- Jiri ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problem with referrers
Hi Jiri What do you think about that? Can you think of any problems this might bring us? I can only think of adavantages. The data classes I've added for managing the history of primitives could possibly be replaced with *Prototype too. The second approach (turning dataset into a factory for primitives) is fine for me too. Dateset.addNode(node parameters..) wouldn't be a static method on DataSet, but a method on a Dataset, right? I'd be happy to help migrating core and plugins to this new approach. Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Jiri Klement Gesendet: Samstag, 3. Oktober 2009 14:18 An: josm-dev Betreff: [josm-dev] Problem with referrers Hi, I'm working on support for referrers and I run into a problem which I'm not sure how to fix. Currently JOSM quite often makes copies of primitive (using for example cloneFrom or special constructors). It's not obvious whether the copy is added to the dataset or is kept in case we need to get back to old version of primitive (for example Command.cloneMap). That's a bit problem because I don't want to have such copy in referrers list, I want only primitives that are really used in an dataset. To workaround this issues I'm thinking about introducing new classes - PrimitivePrototype, NodePrototype, WayPrototype and RelationPrototype. These classes will hold informations for one primitive, but it will not be possible to add these objects to the dataset. That will allow to clearly distinguish what's real primitive and whats just an backup copy for for example Command.cloneMap or Main.pasteBuffer. Obviously it will be possible to construct new primitive based on prototype. Method cloneFrom() and constructoctors like Node(Node n) will be removed to make sure everybody is using new system. This will also fix another issue - for some features (most notably reliable events when primitive is modified) I need for every primitive to be part of exactly one dataset. This can be forced by making all primitive constructors protected and allowing to create new primitives only using methods like Dateset.addNode(node parameters..) or Dataset.addNode(NodePrototype). What do you think about that? Can you think of any problems this might bring us? -- Jiri ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
Dirk Stöcker wrote: On Sat, 3 Oct 2009, Ray Foulkes wrote: ...etc. The reason is easy - Make the data access thread safe. I think there are sync keywords in Java to do so, but I do not really understand Java multithreading completely (I'm more a C/C++ guy :-) Hi Dirk, thanks for responding. I wasn't quite ready to propose what to change to fix the problem, but here goes with my current thoughts... I read JTT's observation attached to the (closed)#3238 ticket: livegps is modifying the gpx track at the same time as EDT is trying to get length of the track to show tooltip text. The exception can be fixed either by making GpxData thread safe (using ConcurrentLinkedQueue for GpxTrack.trackSegs instead of LinkedList will fix this concrete issue) or by acessing GpxData only in worker thread. I agree that it is true that the exception could be avoided by making gpxdata thread safe as JTT suggested using ConcurrentLinkedQueue. BUT I am reluctant to go down that route for the following reasons: 1. It is dangerous to allow unsynchronized access to any data structure (such as Layer and its subclasses) from more than one thread. The main part of JOSM accesses layers(and it subclasses) from the event dispatch thread of swing. JOSM was lucky in the sense that the linked queue being used is concurrency aware (if not concurrency protected) and raised the concurrent modification exception. There may be other accesses simply giving/providing bad data i.e. any access of a non-atomic data item might give some part of an old version and some part of the next to a reader. Even if you could be sure of protecting all the accesses of the current program, someone innocently might add something else which is not synchronized. Unless it can be absolutely assured that the ONLY data changed from any thread other than the swing event dispatcher thread is gpxdata, then simply protecting gpxdata can only be regarded as patching over the problem. Accessing gpxdata only via another thread is likely to incur rather a high overhead for (for example) paint. 2. There is another problem in livegps as follows: The propertychangelistener of LiveGpsDialog accepts gpsdata change events. It then calls javax.swing.JComponent.setBackground (and a few other swing components). Since I am fairly sure that gpsdata bean events are delivered synchronously from the livegpsacquirer thread, it is a non-permitted use of Swing calls see: http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html#threading which explains that the only thread permitted to invoke swing primitives is the swing event dispatch thread. Calling swing components from another thread is undetected by Swing but is banned for a very good reason; nothing is synchronized in Swing. The developers of swing wrote a long explanation as to why this was. It would be possible to program a method of feeding events back into the event system of Swing, all of which are executed on the Swing dispatching thread (unlike the beans events which are synchronous with the thread of the declarer). Then of course, the event handler on the swing thread would have to use synchronized access to anything modified in the livegpsacquirer thread but could legally call swing components. On the other hand there is a recommendation from the Swing developers on how to carry out asynchronous background processing and a package to support it. Essentially it supports feeding a queue of objects back to a method called on the swing event dispatcher thread where swing operations can be invoked. see http://java.sun.com/docs/books/tutorial/uiswing/concurrency/worker.html Sorry this is a bit long but... My initial thought was to try to avoid having to synchronize layer (or its various components) and its sub classes. Doing that would be safe but may incur too great an overhead cost for the rest of JOSM. It might be better if livegpsacquirer returned new objects to a handler running on the swing event dispatcher thread as supported by the Swingworker class. Thus there would be no concurrent access to layer and its subclasses. BUT, I have not yet looked at what other threads need access to layer (and subclasses) in other packages. Hence I am not at this moment sure of my ground. There maybe no alternative to synchronizing various parts of layer and its subclasses, but I think that might be lots of work. There is also some bad news/good news regarding Swingworker; JOSM has only a reliance on SE5, Swingworker is only integrated with SE6. I have downloaded the source of the Swingworker package and it looks as if it will compile and run under SE5 - on the other hand it is Sun copyright, and so delivering it with the package may well be illegal. sigh. As you are aware, at the moment all this is based on code reading since I cannot yet build and debug JOSM + plugins. In summary, I am nervous about simply putting in a patch to stop this exception being raised. It would certainly solve my immediate
Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
On Sat, 3 Oct 2009, Ray Foulkes wrote: In summary, I am nervous about simply putting in a patch to stop this exception being raised. It would certainly solve my immediate problem using JOSM+livegps+surveyor, but I don't think that it would be doing the JOSM project a great favour for the future. Well, time to tell you my view about software development: - There is code development which is done without thinking about future and clean interfaces. - There is development using easy design and having the more complex stuff in mind when designing, but only caring for more complex stuff when it comes up in reality. - There is clean design using perfect structure. If you go to a university they will tell you to use approach 3. Some programmers will tell you to use 1 (which is sometimes good for prototyping). I will tell you to use 1, 2 or 3 depending on situation :-) You see the changes Jiri and Karl have been doing the last months to enable JOSM to handle larger datasets a lot better. Well, both of them currently move some JOSM code from point 1 to point 2, but with a specific goal in mind. They would surely have much less work when the design would have been correct from the very beginning, but the point is, that JOSM would probably not exist at all when design would have been perfect from beginning. Rewriting code is not bad in my eyes. Nobody should expect code to have a long life time. Code as well as requirements change over the time. So when doing the livegps fix choose the best option you find, which - very likely will not introduce more problems later, - when necessary improves the general design without adding lots of useless overhead, - FIXES THE ISSUE. Thinking a bit about future is fine, but don't worry to much. You do not know in which direction JOSM will go, I do not know this, nobody knows. When we get problems we will care for them when they appear. P.S. The suggest approach is no excuse for dumb decision. And also to be able to use the right approach in a specific situation usually needs some experience :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
