Re: [josm-dev] [PATCH] timestamp parsedTimestamp in OsmPrimitive
I did some benchmarks and here are the results: no date handling at all - 17 seconds josm-ng date conversion - 19.5 seconds josm-ng date conversion done with char[] instead of string - 18.8 seconds. josm-ng version is 13% slower but that makes only 2.5 seconds on 80MB file. Also it allows more memory efficient storage of timestamp. I personally would get rid of lazy parsing parsing and use Petr's version. What do you think? On Mon, Mar 9, 2009 at 6:03 PM, Petr Nejedlý p...@nejedli.cz wrote: Jiri Klement napsal(a): Hi, Attached patch replaces timestamp and parsedTimestamp in OsmPrimitive with DateContainer class accessible only using setter and getter. The patch is not much usefull on itself but hopefully its the first step to make OsmPrimitive encalupsed (without public variables) so things like spatial index or better caching will be possible in future. I have read both the patch and the thread and I would suggest something different, once you're touching this and removing public access to the field(s). First, adding another holder class is both unnecessary and a memory waste. You can add reasonable access methods directly to OsmPrimitive (while providing e.g. DateComparator for comparing OsmPrimitive dates, if necessary) and resort to keeping only a private integer timestamp (in seconds, not long millis) inside the OsmPrimitive. This means that you'll need to parse all the timestamps during xml parsing, but if done properly, you won't notice the slowdown. Feel free to use the parsing code from josm-ng: http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/utils/DateUtils.java which I do use quite quickly for datasets much larger that JOSM can even imagine. (I have spent quite some time benchmarking and optimizing the parsing code, you can be sure I know why there was lazy parsing and everything in the riginal code). As long as you hide the field and provide only the Date/String(/int) API, you can reintroduce the String field anytime though (but you won't need to). Regarding your: // TODO Is it enough to compare string representation? Dates can be in different format but are they in real life? No, it isn't. The timestamps seem to be stored in the OSM database in the textual form or at least keep the original timezone information (which is useless anyway) and you'll encounter many different formats (timezones) coming from the OSM server all the time (in the same download). Just download a random area, store to a file and look there. Once you're all integerized, you can remove all the String based code paths to simplify the code. Petr ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On Mon, 9 Mar 2009, Maarten Deen wrote: Dirk Stöcker wrote: On Mon, 9 Mar 2009, David Earl wrote: You have 3 ways to replace this: a) Press ESC instead of Shift b) Press U instead of Shift c) Double-Click to end drawing a node. Methods a and b are long-time and only c is new. These are all workable, but require extra clicks or keypresses after the click and therefore make the process slower. Sorry, but you should try before talking. You can press ESC and U the same way as you did with SHIFT. There is no difference. And when you now tell me that the distance on the keyboard is to large, you can reassign U and Y. So the question really is, why do we need 4 ways for one function? I think 3 are enough. Especially as the SHIFT-Modifier has not been removed only to remove it, but has got a new meaning. It's certainly not that we need multiple ways for one function, it's more that the easy way to do something all of a sudden vanished. And as people are a lazy bunch, we don't want to do anything more that we used to. ;) For me your comments really look like I want my old way and don't even want to try others. It is not that you would need to change your way of work totally - it is only a press another key. 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] [PATCH] timestamp parsedTimestamp in OsmPrimitive
On Tue, 10 Mar 2009, Jiri Klement wrote: I did some benchmarks and here are the results: no date handling at all - 17 seconds josm-ng date conversion - 19.5 seconds josm-ng date conversion done with char[] instead of string - 18.8 seconds. josm-ng version is 13% slower but that makes only 2.5 seconds on 80MB file. Also it allows more memory efficient storage of timestamp. I personally would get rid of lazy parsing parsing and use Petr's version. What do you think? If it slows down the import and has advantages during runtime I vote for the optimized version. I can live with a little bit longer import if the overall performance is increased. 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] Displaying the properties of GPX points
As a GNU/Linux user, I've been thinking of using JOSM as a poor man's Garmin Training Center that would display me the elevation profiles and heart rate and cadence statistics of my bike rides. Displaying the elevation profiles of GPX tracks would be a good start. Any suggestions? As far as I understand, I couldn't use the Garmin software even if I wanted, because it apparently doesn't run under WINE. I'm aware of http://viking.sourceforge.net, which can display the elevation data on the GPX trace itself. I'd prefer something that displayed the data in a mouse tooltip when the mouse cursor is positioned over the track and also in a 2D graph with the time on the horizontal axis and elevation (cadence, heart rate, speed, whatever things that can be derived from the data) in different colours on the vertical axis. I guess I could implement a mouse tooltip for the GPX layer that would display the timestamp, longitude, latitude, elevation, and possibly other attributes. I have no idea how to combine the above mentioned 2D graph with JOSM (or any map viewer, for that matter). Maybe right-clicking a point on the GPX layer could pop up a scrollable graph window that would show the data centered around the selected point. Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Dropped arrows / visualize node connectivity
On Tue, 10 Mar 2009, Florian Lohoff wrote: i just tried to delete my preferences and start from fresh after 1 1/2 Years and i like the visual changes i see. The only missing thing are the arrows on every street. I know i can turn them on again but i'd just like to make a point about visualizing. Typically the arrows indicated quite well if streets were connected. On a crossing both ways would have at least a single arrow towards the common node. Now the arrows get removed completely which is a good thing on one hand but i would prefer a second mode which made arrows on both ends. Example: O-OO ^ | | | This would even more indicate a correct connection between ways. Why? It would look exactly the same even if there are two overlaying nodes in the middle. An even more interesting mode would be to make the first and last nodes arrows on a way different from the others so one could see where a way is split up instead of selecting the way and detect it by the highlighting I put arrows in because it would not necessarily be arrows but some end/start of segment indicator - probably just some change in line thickness or something. We could introduce some other colors/sizes for nodes (i.e. end-node, multi-way-node). That would solve your suggestion. 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] [PATCH] timestamp parsedTimestamp in OsmPrimitive
OK, here is another patch, this time using DateUtils from josm-ng. On Tue, Mar 10, 2009 at 9:08 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Tue, 10 Mar 2009, Jiri Klement wrote: I did some benchmarks and here are the results: no date handling at all - 17 seconds josm-ng date conversion - 19.5 seconds josm-ng date conversion done with char[] instead of string - 18.8 seconds. josm-ng version is 13% slower but that makes only 2.5 seconds on 80MB file. Also it allows more memory efficient storage of timestamp. I personally would get rid of lazy parsing parsing and use Petr's version. What do you think? If it slows down the import and has advantages during runtime I vote for the optimized version. I can live with a little bit longer import if the overall performance is increased. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev timestamp.patch Description: Binary data ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
