Re: [josm-dev] Trouble translating JOSM: Same strings used in different places
Ævar Arnfjörð Bjarmason napsal(a):
> tr("EDIT_MENU_NAME")
> [...]
> The application would then be configured to never use the original
> tr() strings except in some debugging mode, always switching to en.po
> when you start it up.
>
> Maybe this has already been implemented by some other application?
Sure, by every other java application out there. It is called
(java.util.)ResourceBundle
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Fail
Sascha Silbe napsal(a): > On Fri, Jan 16, 2009 at 01:08:35PM +0100, Pieren wrote: > >>> +1 for making this harder to activate (separate mode, ctrl+drag, >>> whatever). It's pretty annoying when trying to select a region in a >>> densely mapped area. >> -1 -1 >> I'm moving ways. I cannot say "every day" but I move ways when I: >> - improve roundabouts (position, circle) >> - draw dual carriageways (copy, paste, reverse, move) >> - draw areas like buildings or parks > How would e.g. having to press Ctrl in addition to dragging impact your > workflow? > I don't see why you're opposed to making it harder to _unintentionally_ > using it. Well, as long as Undo is reliable, making useful feature harder to use/discover is a nonsense. "I helped her find Undo." scares me a bit, though. Ctrl+Z works all around the world and it's even listed in the Edit menu as usual. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] When to move a node?
Harald Kucharek napsal(a):
> When Frederik added my orthogonalization action to JOSM, he remarked:
> --
> There's one thing I do not like yet, and that is that multiple changes
> are generated if you call the function repeatedly (it doesn't recognize
> that the shape is already rectangular, makes minuscle adjustments). I
> tried to build in a treshold under which there would be no change
> recorded but it didn't work out well.
> --
> It seems, this hold for all similar actions, like "Align nodes in
> circle" etc.
>
> Frederik used from LatLon this method:
>
> public boolean equalsEpsilon(LatLon other) {
>final double p = 1/Projection.MAX_SERVER_PRECISION;
>return Math.abs(lat()-other.lat()) <= p &&
> Math.abs(lon()-other.lon()) <= p;
> }
>
> where
> /**
> * Minimum difference in location to not be represented as the same position.
> */
> MAX_SERVER_PRECISION = 1e12;
>
> Almost all operations will make this method return false, just due to
> numeric inaccuracies, I guess. Also, this is a very non-intuitive test.
No wonder, the used epsilon, on a +-180 degree scale leads to comparing
49 out of 53 bits of double mantissa. 4 bits of error will easily accumulate
over few operations. The epsilon also transforms to something like 100nm
(yes, 100 nanometers) on the earth surface.
>
> I made a quick change by using
> public double greatCircleDistance(LatLon other)
> also from LatLon, only really moving nodes when the distance computed by
> above method is less than 2 meters (the method computes the distance in
> meters).
2 meters is way too much, you certainly want to fix smaller errors.
2m is like 21 out of 53 bits, so we have 28bit scale in between to pick from.
I don't expect the numerical errors much bigger than those 4 bits (unless the
algorithm is flawed on the error propagation front, I haven't analyzed that
much).
If we add 10 bits (epsilon of 1e-9) to have a plenty of headroom, we're still
at around 0.1mm accuracy.
So, you can either keep using equalsEpsilon and update epsilon to 1e-9
(enough accuracy IMHO, but needs wider acceptance, as this has much deeper
impact,
like comparing nodes on merge), or change the limit to getCircleDistance
to 0.0001m. The former is faster code
> This way, it is very clear when a node really moves and when not. I had
> no time for long tests, but it seemed to me that the computed distance
> is either smaller than expected or the scale of the map, as nodes I
> expected to move weren't moved. I've to check this next weekend.
> Sure, greatCircleDistance() is computationally much more expensive than
> equalsEpsilon(), but we usually don't move millions of nodes.
>
> That was my idea. Now, any other ideas or thoughts about the problem?
>
> Regards,
>
> Harald
>
>
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/josm-dev
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM charset
Dirk Stöcker napsal(a): > On Tue, 2 Sep 2008, Frederik Ramm wrote: > >>> now that I found a charset conflict in measurement plugin: Is there any >>> definition in which charset the jar files are? >> >> You mean the java source code files? I don't see why they should be >> anything else than good old 7-byte ASCII. We don't want any national >> language characters in there anyway (they belong to the language >> plugins). But since a 7-byte ASCII file is, by definition, a valid UTF-8 >> file as well... I don't care. Just don't put anything above 0x7F in your >> source, ok ;-) > > Well, the problem is measurement plugin, which uses degree symbol "°". > > Not so easy to get that into ASCII except writing "deg". "\u00B0" -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Combining mappaint styles
Dirk Stöcker napsal(a): > On Wed, 27 Aug 2008, Ulf Lamping wrote: >> My first thought was to use something like a specially dashed (dotted, >> ...) way, but that would be hard to distinguish from other dashed stuff >> (like tracks) and also probably hard to "visually get" for very short >> bridges (tunnels). > > What about alpha shaded lines? E.g. if you overlap a street with a 20% > black line for tunnel or 20% green for bridge or something like that. > >> Obviously, I haven't tried this out, so the best would be to have a >> prototype and have a look at it :-) > > Well, the design of the XML and the implementation depends a lot on the > fact how to display it later. In josm-ng, I'm experimenting with multistyle, where each tag can add a (list of) stroke(s) (painting primitives) to apply, and all the tags are processed for given primitive (not ony the first one that matches). This is what would you get for a way with highway=seconday and railway=tram: http://shell.sh.cvut.cz/~nenik/josmng-multistyle2.png Still, one tag can't (easily) influence a stroke based on another tag (like the alpha/dashed painting for tunnels) in my scheme. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Performance optimizations
Dirk Stöcker napsal(a): > Hello, > > Jörg Henne ist currently developing a set of performance improvements > for JOSM. > > Find the patch here: http://www.dstoecker.eu/2008-08-21.patch > > Here his note: > --- > Attached you'll find a patch against JOSM #813 which enhances the > performance of certain common operations: dragging nodes and ways and > selecting/deselecting elements. Please apply copious amounts of testing > and/or abuse. I can't help myself but ask: Were there any measurable performance gains by this change? No matter how am I looking at the patch, even completely sober today :-), all I see is worse performance for large datasets - the "real-time" damage computation would iterate the whole data set several times for every repaint (including style resolution), then slightly reducing the paint "aperture". Or am I smoking something? Well, maybe I have a different view on what "large dataset" is. An order of magnitude different. Or two. But when I'm mapping a larger trip over Czechia these days and download a rectangle here and a rectangle there, it quickly adds up (note that the project Czechia have recently imported all the forests). -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Performance optimizations
Dirk Stöcker napsal(a): > Hello, > > Jörg Henne ist currently developing a set of performance improvements > for JOSM. > > Find the patch here: http://www.dstoecker.eu/2008-08-21.patch It would be fine if Jörg cold separate the real functional patch from all the unrelated formatting changes. It is quite hard to follow the semantics of the change in all the noise... If I were sober, I could have followed the patch in this form too, but not now ;-) -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Path to spatial index [long][Was: Refactoring of the JOSM architecture vs. Plugins]
jh napsal(a): > Petr Nejedly schrieb: >> Right. You do some attempts on relation rendering, so filtering them >> will come handy. >> Not because there are many of them (to the contrary), but because the >> index API >> would be very simple then: Iterable >> giveMeAllThePrimitivesInside(Bounds bounds); >> (or better "visitAllThePrimitivesInside(Bounds bounds, Visitor vis);" >> > Speaking of bounds: I saw that in -NG your QTree indexes all primitives > by bounds. Have you considered indexing ways (or rather their segments) > by intersected (crossed) nodes instead of using the segment bounds? I > guess with a bucket size of 100 that might not make that much of a > difference, because segments are usually relatively short compared to > the node density, but you might have had other reasons as well. The reason is that you can have a way that crosses current screen, yet none of its nodes are on the screen. Long way on close zoom, for example. For a nice graphical explanation, see: http://wiki.openstreetmap.org/index.php/QuadTiles#Indexing_tile_intersections >> Not initially, but you will, earlier or later, end up caching the >> associated style too, >> (this is the "below" where you'll clutter OsmPrimitive with another >> field) and this is >> tags dependent. > Yes, also because damage tracking is dependent on the visual (pixel) > extent for a primitive which, in turn is style dependent. This is something I don't currently deal with, so it may (rarely, see below*) happen that when you should see a half of the icon on the edge of the screen, the icon might not render at all. The simplest workaround for this is to just add enough pixels to the bounds before asking the index. *) Because the quadtile indexing is rough (that is, you usually already get more data than you asked for), the problem would only be visible on the very rare case when a node ends up very close to the quadtile border and you hapenned to have similarly positioned viewport. >> Also, the index might take current zoom into account too and structurally >> filter out unimportant (highway=residential, untagged node) primitives >> when looking >> at the whole shebang. See: >> http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/view/osm/View.java >> >> >> > Great Idea! Very roughly realized in: http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/view/osm/ViewData.java see qGet() (and the other q* functions) In reality, the qTree alone could take care of the detail level. The next trick would be to generalize the ways for wide zooms and keep exact data for close zooms. >> The second important thing is the way you'll react to modifications. >> You've got the hook >> in the form of setCoords, so what would you do? >> 1. Update the index for given Node (that is, remove and readd it) >> 2. Find all the referers (ways, relations). Well, (d) from third >> paragraph has higher >> importance, it seems, as long as you don't have self-consistent >> backref baked into >> the DataSet (josm-ng does) >> 3. Update referer bboxes (maybe recursively) >> >> Is this right? NO! Imagine a user drags a 4000node forest (there is >> one such in Germany, >> and I've even been (physically) to one 5500+ nodes in Poland recently >> ;-) ) >> You're going to get 4000 node updates and you're likely to end up >> visiting all the 4000 nodes >> each time to compute the new bounds (4000^2). > Sorry, you've lost me with the -squared. Why would we have to visit all > other nodes per node? So you get an independent event that node N1 have moved. You have no idea there are additional 3999 events to come, so you look up all the N1's ways (let's say that there's only one, W1). If you want to be correct, you have to visit all W1's nodes and compute the new bbox - this covers the case when the N1 was an extreme node and by moving it, the bbox shoudl shrunk. Thus N^2. You can opt to err on the safe side by only checking whether the bbox is now larger after the move, this would slash the cost back to O(N). With the queue, you're at similar complexity while staying exact. Moreover, there are relations and if you want to track their bounds too, and when there's a hierarchy of them, oh well ... >> Also, possibly traversing a large hierarchy >> of relations (there is one such in Germany, covering all the >> motorways, boundaries and so on) >> each time won't be nice too. Safer is to: >> 1. Add the node to a queue. Period. Full stop. >> OK, 2. before each index inquiry, collect al
[josm-dev] Node rendring fix
For a long time, I have suffered from a random problem that nodes on some ways were not visible (were under) with mappaint and close zooms. This makes slight updates to nearly stright ways very frustrating. I have finally uncovered the cause of the problem and fixed it. Please apply the following trivial patch: Index: src/org/openstreetmap/josm/data/osm/visitor/MapPaintVisitor.java === --- src/org/openstreetmap/josm/data/osm/visitor/MapPaintVisitor.java (revision 808) +++ src/org/openstreetmap/josm/data/osm/visitor/MapPaintVisitor.java (working copy) @@ -330,10 +330,11 @@ osm.visit(this); } + displaySegments(); + for (final OsmPrimitive osm : data.nodes) if (!osm.incomplete && !osm.deleted) osm.visit(this); - displaySegments(); } /** The problem was the delayed painting of the last few ways, quite certainly the ways you're currently working on. This patch forces the flush of the accumulated path. I took the liberty and moved, not copied, the displaySegments() call, as I know nodes don't use this facility, but should you consider it unsafe, just ignore the second part of the change. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Path to spatial index [long][Was: Refactoring of the JOSM architecture vs. Plugins]
Frederik Ramm napsal(a): > Ok, then let's do it in small steps in order to (a) break as little as > possible and (b) give everybody a chance to understand what's happening. > Let's make the spatial index our concrete goal and do whatever is > required to get this off the ground. This is very constructive approach, thanks. With the risk of explaining obvious, let me describe the spatial index related design decisions I made while implementing josm-ng, the reasoning behind them and how do I evaluate them now. This should help us understand required granularity of the changes and impact of the decisions on different (josm) model. When I'll talk about memory usage, sample data would be germany.osm with around 8M nodes and 1M ways - a dataset that is usable in josm-ng on a 2GB RAM (~1GB java heap). Note also that I might be wrong on some of the josm's inner workings, having spent much more time on the -ng codebase. > Do you propose having the spatial index as part of the OsmPrimitive > object, or would you recommend having an extra "display" object instance > to sit next to each OsmPrimitive that handles these things? The index is not going to be "inside" OsmPrimitive - it is going to index the primitives themselves. So it has to be either part of the DataSet or part of the OsmDataLayer. Let's look at the use cases (API clients) for the index: A) rendering. No question about it. You want to render only the things on the screen. B) selection. Whereever you click, josm tries to find the thing you have clicked on. Having a filter here is very desirable for larger datasets. B1) thing-under-cursor-in-status-line. A variation of B, have to be superfast. c) merging - when merging DataSets, the MergeVisitor tries to match new nodes (id=0) if they have the same coordinates. But given that merging is already fast enough and this may unnecessarily complicate the code, I won't emphasis this. d) back references lookup - again filtering the candidates would speed up things tremendously. The first decision is what to base the index on. You can index either according to latLon (1,model space) or eastNorth (2,viewSpace). Both (A) and (B) support (2) and this is what I did in -ng. Less important (c) and (d) would vote for (1) and you can always transform the filter rectangle between coordinate spaces, at worst enlarging it slightly. Now back to the "extra display object" - this is what I did in -ng (View class), and it would slightly correlate to the eastLong field of josm's Node. This was a clean-design design decision: I have a model (DataSet) that contains only the primary (osm) data, then I have a view cache inside the OsmLayer view implementation, which is completely transient - I can recreate it anytime just from the primary data and this is what I really do e.g. in case of runtime projection switch. In theory, I could have two views of the same DataSet visible at once, each of them in different projection. Also, I could parse a DataSet for some batch processing and there will be no unnecessary clutter wasting my memory. This is the good side. The bad side is increased memory usage for the common (editing) case. For each model entity, there is a view entity (at least 8B on additional object header, 72MB for germany). There is also a mapping between the two (64MB in quite densely populated Storage's object array, don't even think of HashMap, and another hypothetical* 32MB in back references) and a view-hierarchy equivalent of all the Way's node collections (50MB). All in all, 30% more memory. For josm, we should for long stick with single entity (it comprises so many objects already anyway) and that makes indexing by lonLat a very viable option. At the cost of making OsmPrimitive even more cluttered later (see below) *) JVMs typically have 8B object size granularity, so, simplified, every second field is for free. > We'd need protected access to the node position Right. I would even go as far as updating the other coordinate automatically. On the other hand, most of the position writes should go through the MoveCommand anyway, so it won't be that painful. > and member list for ways Right. This looks more painful on the first sight, but given the fact that every commited node list modification should be done by ChangeCommanding the old way with a new one, it's theoretically done already. But there's an opportunity to enforce that contract (and that is, prevent undo system from a disaster caused by a random plugin) once we're touching the code. There are 1,5 options here and taking this path means quite a lot of changes instead of none: 1. Let nodes be a read-only view of the actual nodes collection. Everybody would _have to_ create a new way to set the nodes. The pattern would then change from: Way wnew = new Way(wold); wnew.nodes.add(node); cmds.add(new ChangeCommand(wold, wnew)); to
Re: [josm-dev] Difference between JOSM and JOSM-NG
Till Amma napsal(a):
> It is good to know that there are two approaches right now. JOSM-ng for
> the guys liking encapsulated, design pattern driven code. And the existing
> JOSM providing a more loose access to fields making it easier to implement
> things.
Kind of marketing follows
Sorry, I couldn't resist: Ha ha ha.
Well, I just crossed the unglue plugin (just in time, project Czechia have
finished forests import, policy for roads adjacent to forest is to share nodes
and some mappers were concerned that such a thing is very hard to modify in
josm)
and tried to reimplement the same functionality for -ng
I did it in few minutes and the code is nice, readable, stright and short.
The action body has around 40 lines including all the checks in -ng.
The splitting function alone in josm chimes in at ~73 lines with deep nested
block,
with another 40 in checks. Well, I could rewrite the josm's version to be nicer
and shorter using back references visitor and so on, but it would still need to
deal
with all the cloning of changed primitives and those change commands...
Ah, I know, it's called marketing. That part of in-this-thread-mentioned economy
which may actually lure more developers to given project, orthogonally to the
real
shape of the code and so on.
So let me place a shameless plug here:
public @Override void perform(OsmLayer layer, DataSet ds, ActionEvent ae) {
CollectVisitor cv = layer.visitSelection(new CollectVisitor());
if (cv.getWays().size() > 0 || cv.getRelations().size() > 0 ||
cv.getNodes().size() != 1) {
JOptionPane.showMessageDialog(null, "The current selection cannot
be used for unglueing.");
return;
}
Node splitPoint = cv.getNodes().iterator().next();
CollectVisitor refs = new CollectVisitor();
refs.visitCollection(splitPoint.getReferrers());
if (refs.getWays().size() < 2) {
JOptionPane.showMessageDialog(null, "You must select a node that
is used by at least 2 ways.");
return;
}
List newNodes = new ArrayList();
Iterator ways = refs.getWays().iterator();
ways.next(); // leave the first way alone
// every other way get its own copy of the node
while (ways.hasNext()) {
Way act = ways.next();
Node copy = cloneNode(ds, splitPoint);
newNodes.add(copy);
List nodes = new ArrayList(act.getNodes());
Collections.replaceAll(nodes, splitPoint, copy);
act.setNodes(nodes);
}
// every relation using splitPoint gets all its clones as members with
the same role
for (Relation rel : refs.getRelations()) {
String role = rel.getMembers().get(splitPoint);
for (Node n : newNodes) {
rel.addMember(n, role);
}
}
}
That's all. Please compare it with your copy of unglue plugin sources.
It is also fast even on huge dataset (no full-DataSet iteration. getReferers()
call is fast as well).
Oh, and it doesn't duplicate a node used several times by a single way. Should
it?
(The original unglue would turn a closed way (abovementioned forest) into an
unclosed
one in case you happened to be ungluing just the start=end node of the forest).
Does undo work after such an action? Sure!
Just commited to -ng, r9962
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Refactoring of the JOSM architecture vs. Plugins
Robin Rattay napsal(a):
> J.H. schrieb:
>> - Introduce an API version management for plugins (let a plugin return
>> its expected API version. Assume pre-version-management version on
>> NoSuchMethodError).
>> - Make it easy for refactorers to run a workspace with all the
>> (critical) plugins checked out.
>> - By the way of refactoring, clean up the code design, and create
>> well-defined APIs as we go along.
>> - Publish API change notes to give third-party plugin developers a
>> chance of keeping up.
>
> It may be a dumb idea, but what about using a rich client platform like
> Eclipse or NetBeans? That way you get things like a plugin
> infrastructure built in.
Yes, at a cost. Is the benefit of the platform worth the cost?
Moreover, at least NetBeans expect that a plugin API evolve
in a sensible way, that is, every plugin designed for lower version
should work with higher version of given API. Of course, there is a possibility
to claim that your API changed incompatibly (changing so called major version
of the API providing module), but it is used very rarely in the NetBeans land
("preservation of investment").
Note: Of course I think NetBeans is a great platform. I just thing it is
still too big for the project of the JOSMs size.
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Nic Roets napsal(a): > On Mon, Aug 11, 2008 at 8:11 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: >> But with JOSM-NG sitting around untouched by anyone but Petr himself, >> and this for the best part of a year, the argument that a properly >> designed JOSM would attract more programmers rings hollow. What JOSM >> currently needs most is a few people who share the responsibility, who >> make JOSM "their" project and who are willing to do more than submit the >> occasional patch. It seems to me that JOSM-NG, despite its clean >> architecture and technical superiority which I don't doubt for a second, >> has not managed to find these people either. > > A few hints to finding these people : > * Don't call it JOSM-NG. JOSM already has a bad name. This is the second time I hear this. > * Get people to use it before you invite them to write plugins. That > means limit the scope of the project, but make sure it all actually > works (incl. uploads). Yes, that's high on my priority list, but I can't help myself from time to time and let myself get distracted bu something less important. And I am also a mapper myself, so whenever I return from a new destination, I rather map than code ;-) > Is it true that JOSM-NG will have a different upload process ? Not at > the end, but while the user was editing ?? If so, I would not consider No. And it wouldn't make much sense under 0.6 OSM API > it superior because of the added complexity. ... but why do you think it would add complexity, and why would you judge superiority based on complexity? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Frederik Ramm napsal(a): > Can we make it mandatory in the future for everyone whining about JOSM's > programming model to explain why they're not working on JOSM-NG? ;-) So I can whine all the time... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Jonathan Bennett napsal(a): > Petr Nejedly wrote: >> When thinking of it now, I don't think starting josm-ng was a bad idea. >> It allowed me to prototype my ideas quickly and some of the ideas can >> still be taken from josm-ng and ported to josm. > > > Petr, just out of interest, why didn't you base josm-ng on the NetBeans > platform, given your day job? This was my very first thought when I've seen JOSM source code for the very first time. It has plugin system, menu registrations, kind of windowing system, toolbars, I18N, update center. Even NB palette would be useful (for presets). Now think of it more: josm.jar was around 900kb at that time, stripped down NB platform is around 6MB. Who's gonna buy that? There's a lot of stuff in NB that JOSM would have no use for (nodes, filesystems), or would unnecessarily add complexity (datasystems), yet are important part of the platform and e.g. windowing system (which would be great addition to JOSM) depend on them. Given that some of the NB platform concepts have made it into the JDK already, or can be stripped down to a class or two, and given that I started with a simple OSM parser and a data model (just to test how small/fast would that be) first, I followed the route of adding individual concepts as they are needed rather than starting with a huge platform and a very tiny addon. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Evgeny Mandrikov napsal(a): > Why are you using ant instead of maven in JOSM-NG? The obvious answer is 42 of course... Guess what. I just created a new J2SE project in NetBeans and it created an ant script for me with all the bells and whistles. It helps me debug, it helps me profile. On the other hand, it uses custom ant extensions, so you can't easily build the project w/o NetBeans installed. I'm going to address this soon though. What would Maven bring to the table for a simple J2SE project with no dependencies, single source folder and single dist jar, anyway? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Bug 595 - Virtual nodes - Comments requested
Dirk Stöcker napsal(a): > On Mon, 18 Aug 2008, Petr Nejedly wrote: > >> I just don't like the appearance of the "virtual nodes". Could you turn them >> into >> small (nonzoomed), thin red plus signs instead of rendering them the same >> style >> as the way they sit on? > > Sure. In SimplePaintVisitor there is one function drawing the virtual > nodes. This needs to be adapted. > > If I find out how I can change the style without disturbing to much other > program behaviour, I will do so. > > Patches welcome :-) Not that simple thanks to the way SimplePaintVisitor tries to collect all the strokes of one kind together and flush them at once. Is there a measurable benefit of this approach opposed to naive implemetation that would just set colors and draw segments as they come? In Josm-ng, I use the naive approach when it comes to graphics primitives, yet it is very fast even on large datasets. Maybe the other optimizations overweight the cost of cloning and setting up Graphics2D for every paint? Maybe it depends on a graphics card? (Well, I run an underclocked GeForce 8600M) If the speedup gained by batching same strokes is neglible, we can easily port a Drawer/Part from josm-ng: http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/view/osm/Drawer.java It would improve rendering as you could easily enforce layering (nodes always on top of ways, even the layer/tunel/bridge way attributes can be honoured) and you can easily post-render such virtual entities without looping all the primitives once again. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Petr Nejedly napsal(a): > Dirk Stöcker napsal(a): >> On Mon, 11 Aug 2008, Frederik Ramm wrote: >> >>> Gerv also hinted at the fact that JOSM is written in a way that is >>> somewhat untypical for Java, and whenever a newcomer to JOSM programming >>> said "this is all bullshit let's refactor it wholesale" I told them to >>> please find another project to refactor wholesale. I always thought that >>> the peculiar way in which JOSM is done has a lot going for it and makes >>> it easy to work with the code. > > When we're at it, I'm not sure the way josm is written makes it any easier > to work with the code. Using accessors is the standard way every java > programmer > understands and the code clutter is not much of an argument. > Moreover, josm uses unusual L10N way (I must admit that for a reason this > time, > though not a strong one) and unusual (and harder for anybody writing DataSet > modification actions, easier to break) undo system. Well, I should know better than to (re)start a flamewar and leave for a vacation :-) I'll try to answer comments/questions relevant to josm-ng later today... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Bug 595 - Virtual nodes - Comments requested
Dirk Stöcker napsal(a): > Hello, > > in revision 805 I implemented a new feature I want to know your opinions > about: > > Virtual nodes. > > When in select mode and the displayed way is long enough, in the middle of > the way a little + is added. When clicking this, a new node is created, > which can be used immediately. This makes adapting existing ways a lot > easier I think. I always wanted this functionality in JOSM (josm-ng allows you to immediately drag a newly added node - no select vs. add mode), being tired of all the 'U', 'N', click, 'S', drag, ... (or 'N', shift+click several spare nodes, then drag) I just don't like the appearance of the "virtual nodes". Could you turn them into small (nonzoomed), thin red plus signs instead of rendering them the same style as the way they sit on? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Dirk Stöcker napsal(a):
> On Mon, 11 Aug 2008, Frederik Ramm wrote:
>
>> Gerv also hinted at the fact that JOSM is written in a way that is
>> somewhat untypical for Java, and whenever a newcomer to JOSM programming
>> said "this is all bullshit let's refactor it wholesale" I told them to
>> please find another project to refactor wholesale. I always thought that
>> the peculiar way in which JOSM is done has a lot going for it and makes
>> it easy to work with the code.
When we're at it, I'm not sure the way josm is written makes it any easier
to work with the code. Using accessors is the standard way every java programmer
understands and the code clutter is not much of an argument.
Moreover, josm uses unusual L10N way (I must admit that for a reason this time,
though not a strong one) and unusual (and harder for anybody writing DataSet
modification actions, easier to break) undo system.
I would put it this way: josm-ng currently is mostly an experimental platform*
trying whatever is posible to do regarding memory usage, editing/rendering
speed,
and currently rendering accuracy (my current, uncommited code has a provision
for
defining rendering of relations and can even render holes in multipolygons,
not taking about different rendering available for different zoom levels,
all this real-time up to the dataset of size of germany.osm).
Some of my ideas can be backported to JOSM directly ("Storage" class, which is
a kind of HashMap with much smaller footprint), some with much more effort,
"thanks" to the way josm is written (keeping a bbox of ways, having all the
primitives stored in a QTree - the QTree approach needs the position writes to
be
intercepted, public fields is a big no-no for this).
*) Well there are only about two unimplemented things preventing josm-ng
to be used as a real editor - server I/O (reader part is there, of course)
and tagging UI.
> BTW: I never would suggest or accept "major" changes. Every major change
> can be cut in pieces and introduced as smaller changes. This means you
> always have a stable working software compared to a large refactoring
> period. You have to write some intermediary code, but that also means half
> finished reworks (when the author no longer has time or interest) are
> better than nothing :-)
Well, I can write a List implementation that would notify me about all the
content changes, so I can keep the Way's bbox consistent even w/o disabling
direct access to the Way.nodes field (and thus preventing patching next to
every josm source file for this step just to start optimizations), but for
other things (again thanks to the josm "openness"), such a large change
might still be the very minimal prerequisite :-(
When thinking of it now, I don't think starting josm-ng was a bad idea.
It allowed me to prototype my ideas quickly and some of the ideas can
still be taken from josm-ng and ported to josm.
I'd like to write a summary wiki page, but haven't had much time for it yet.
(writing documentation is much harder for us, programmers, than writing code
;-))
I'll try as soon as I return from vacation.
It might at least remove confusion and maybe help somebody porting useful things
from -ng or the other way around ;-)
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n -- why not Locales & Bundles?
Frederik Ramm napsal(a): > Hi, > > I don't know why we're using what we're using; maybe a design decision > by Imi. Anyway whatever reasons were valid then must not necessarily be > valid now. > >> My primary reason for asking is that I can't get JOSM to build under >> NetBeans -- the latest version of the xnap-commons library lacks the >> translation functions used. You should use the lib/gettext-commons-0.9.jar that is part of the checkout. > I believe Petr Nejedly has successfully run JOSM with NetBeans. You can use the following (maybe slightly outdated) patch to turn your JOSM checkout into a NetBeans project: http://shell.sh.cvut.cz/~nenik/josm-build.patch -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM rendering improvements the last days - I'm guilty!
Bodo Meissner napsal(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ulf Lamping wrote, on 15.07.2008 01:00: > > | But the most remarkable change I've done is to add some rules for > | stuff that *shouldn't* be used IMHO. > [...] > > | All in all: If you find a "no parking sign on a bright yellow ground" > | or a bright red dashed line you probably may rethink your tag - > > It is a good idea to do these checks. It helped me to find some nodes > with highway tags that probably have been added by accidentally adding > the node to a set of selected way segments. > > But IMHO it would be better to add these checks to the validator plugin, > not to the rendering mechanism. Disagreed (to some degree). While the checks should certainly be in the validator, seeing them offhand without running a tool, especially as soon as you make a mistake is very valuable too. (On the other hand, having validator plugin immediatelly check just created/modified entities would solve most of this). -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] downloading data along a gpx track
mariner napsal(a): > Hi there, > > There is one feature I am really missing in JOSM. It's the ability to > donwload the data of OSM near a gpx track. > > I would like to place a feature request here on the list. > > It would be great to get only the data from JOSM, which is really > important. This is mostly beside a track. Maybe 100 meters on each side > around the logpoints. Would something like this be possible? I would > like to help, but have no idea where to start... You'd have to tile your cover area with rectangles and then ask the server for each such a rectangle separately (as the OSM API only supports asking for one rectangle at a time) and merge the resultant datasets. It might end up being much faster to actually download the big rectangle over all your GPX data (unless you cross the server request limit, of course). Now, depending on your motivation, it might be enough to take that big rectangle and filter it locally. If your concern is JOSM responsiveness/memory consumption, local filtering might work well. If your concern is the server limit, cutting the coverage into pieces digestible to the server is the only way. It would be useful addition anyway, as it could support other use cases too. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Resource Handling in josm-ng
Raphael Studer napsal(a): >> So the only thing I'm working on is the stylesheet, but not verry >> succsesfull.. > > Don't know what i did wrong, but now it works. > I copied the josm elemstyles.xml and it's verry fast :) Yes, it is*. Now let's make it really usable too *) Last week I tried whether I can make it swallow a dataset of the germany.osm size, and with few mods**, I can indeed load germany.osm (~8.5M entities) with a java heap slightly over a GB and it is still usable (though slow) for whole-germany view and pretty fast for closeup panning/editing. So while I had more ideas on making josm-ng even less memory hungry, they would unnecessarily complicate the code and I'm abandoning them for now. **) One is direct timestamp parsing, so no expensive timestamp strings are held on the heap. This is already in the SVN. The other is replacement of the giant TreeMap index in the ViewData with a sorted array, but that needs more work to be a valid solution. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Resource Handling in josm-ng
Petr Nejedly napsal(a): > Raphael Studer napsal(a): >> I don't know if Eclipse uses ant to build projects. Or if this can be >> defined somewhere.. > I don't know either, but I'm sure eclipse can easily handle multiple > source roots. See the josm's .classpath file. > >>> I will need to implement richer style semantics for the HiFi rendering >>> anyway, >>> then I'll bundle my own style file (with different syntax). >>> But I'll have to copy the icons then. This setup allowed me to avoid >>> source-level copying. >> Whats about just include the icons in the svn? Like the tilesAtHome >> includes the osmarender and the orp? [...] > So I'll try to clean it up, link it better, directly into the src folder > and get rid of the other source root altogether. Wish me luck OK, I did the cleanup, try it now with a single source root. You'll see what I see out of the box with my (slightly modified) copy of elemstyles finally in SVN. Keep in mind that if you open an .osm file, view will still be centered around my village, so you'll need to do a bit of zooming and panning to actually see your data BTW: Feel free to commit an eclipse project definition if you happen to create one. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Resource Handling in josm-ng
Raphael Studer napsal(a): > I don't know if Eclipse uses ant to build projects. Or if this can be > defined somewhere.. I don't know either, but I'm sure eclipse can easily handle multiple source roots. See the josm's .classpath file. > >> I will need to implement richer style semantics for the HiFi rendering >> anyway, >> then I'll bundle my own style file (with different syntax). >> But I'll have to copy the icons then. This setup allowed me to avoid >> source-level copying. > > Whats about just include the icons in the svn? Like the tilesAtHome > includes the osmarender and the orp? Well, thanks for the tip, but I never used _that_* feature of SVN before. I did some learning, tried to link styles/standard/icons to the shared icons folder but somehow screwed it up ;-/ So I'll try to clean it up, link it better, directly into the src folder and get rid of the other source root altogether. Wish me luck *) I can't even _name_ the feature now. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Resource Handling in josm-ng
Raphael Studer napsal(a): > Hi, > > I tried to use the josm-ng and get a null pointer at > org.openstreetmap.josmng.view.osm.Style.parseRules (Line 69) while > opening the /styles/standard/elemstyles.xml file. > > To fix this, I had to add the styles folder somewhere in the eclipse > project preferences. There are two "source roots" defined for the project - /src and /styles. Both are configured properly in the NetBeans project definiton and I haven't tried opening the project under eclipse. Styles are under separate source root to allow simple redirect to other styles source - the bundled style is in fact empty and so rendering falls back to wireframe rendering. I'm mostly using the mappaint styleset by putting: src.styles.dir=../josm-trunk into nbproject/private/private.properties And if you just invoke ant inside the root folder of the project it should build everything the same way as in NetBeans IDE, including such a private style redirect. (hmm, it seems that you may need to have NetBeans installed anyway to build it this way, it uses some NB-specific ant extensions...) > Is there a possibility to add the resource without changing project > settings for an IDE? Well, you can still create the style file "styles/standard/elemstyles.xml" directly under src folder, classpath is classpath. I will need to implement richer style semantics for the HiFi rendering anyway, then I'll bundle my own style file (with different syntax). But I'll have to copy the icons then. This setup allowed me to avoid source-level copying. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Starting a new way with one selected
David Earl napsal(a): > At present if you are in the Draw Nodes mode and you have nothing > selected, you can SHIFT+CLICK to > (a) add a new node in a blank area, or > (b) add a new node in an existing way, or > (c) select an existing node in the middle of a way, or > (d) select an existing node at the end of a way > and then extend from the new or existing node (in case d, extending the > way, and in the others creating a new way) > > However, if you already have a way selected, cases c and d don't work. > > Can anyone think why they shouldn't? Or is this just a bug? Perhaps its > that the SHIFT modifier doesn't really do anything different if nothing > is already selected. > > This is the most common case where you have to still switch modes at the > moment - you create a way, and come to its dead end (say), and then you > want to do another starting from an existing intermediate node (case c), > possibly in the way you just created, possibly in some other way. Being > able to use the SHIFT modifier would remove the need to SELECT-MODE, > CLICK, DRAW-NODES, would be consistent and would mean you'd hardly ever > need to go into select mode when drawing ways. You're probably right, but you can also use 'u' shortcut to clear the selection... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
[josm-dev] HiFi rendering [Was: Hi List!]
Raphael Studer napsal(a): >> Concerning JOSM development, Fred will surely share some ideas. What Fred >> mentioned a couple of days before at osm-dev was building a cool editor for >> mobile devices. I recently tried to run josm on a N810. It eat almost all of >> my resources, dialogs have been to huge and it didn't respond to stylus/mouse >> press events. >> >> I have no clue if Fred already knows that it is impossible at all to make >> josm >> running on mobile devices. If not I wonder if it was worth the effort. At >> least it seems to be very promising to map details such as housenumbers and >> other POIs live while being outside. >> >> Any comments welcome, > > There is an application for mapping: http://www.tangogps.org/ > but it's not a full editor yet. > > Pushing the JOSM forward could also be done by "combining" josm with > josm-ng (http://svn.openstreetmap.org/applications/editors/josm-ng/). When we're at this, I have a proof of concept for "HiFi" rendering (locally only, not committed to josm-ng repo yet). See: http://stoupa.sh.cvut.cz/~nenik/josm-ng-hifi.png It is still able to paint large datasets in real time, but much better. It uses partially ordered painting to get the layered features stand out. But I haven't yet figured out how to make the transition between layers smooth. As you can see, there are artifacts between layer=1 and layer=2 segments (this is slightly modified map over real data in the DB to move the transition out of the crossroad to verify smooth join on crossroads). Mapnik doesn't seem to solve this at all (it just put all the outlines at the very bottom, so you don't see much about the real layering for the same kind of road). Osmarendered seems to perform the same as me too. (see http://www.openstreetmap.org/?lat=50.0414&lon=14.40841&zoom=17&layers=0BFT but there is the layer change directly in the crossroad - the outline in the crossroad thus confuses anybody reading the map) Is there a better approach to this problem? It's about midnight here and I'm loosing ideas... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] [PATCH 01/26] Enhance OsmPrimitive a bit
Dave Hansen napsal(a):
> On Tue, 2008-04-29 at 15:20 +0200, Frederik Ramm wrote:
>>> @Override public final boolean equals(Object obj) {
>>> - if (obj == null || getClass() != obj.getClass() || id == 0 ||
>>> ((OsmPrimitive)obj).id == 0)
>>> + if (obj == null || getClass() != obj.getClass())
>>> + return super.equals(obj);
>>> + if (id == 0 && ((OsmPrimitive)obj).id == 0)
>>> return super.equals(obj);
>>> return id == ((OsmPrimitive)obj).id;
>>> }
>> In a case where id == 0 but obj.id != 0, the old code would have
>> returned super.equals(obj), while your code returns false. I suspect
>> it doesn't matter much - but was that a deliberate change and if yes,
>> why?
>
> No, not a deliberate change. Probably just me misreading the code.
> But, if I misread it, maybe others do too. :) Probably good to clean it
> up.
BTW: There's _no_ semantic change anyway, taking into account the semantics
of Object.equals (as Object is the direct superclass).
Both implementations would return false.
Anyway delegating to super implementation in case it will always return false
still makes the code obscure and consider my implementation (in josm-ng)
clearer:
public @Override boolean equals(Object obj) {
if (id == 0) return obj == this;
if (obj instanceof OsmPrimitive) { // not null too
return ((OsmPrimitive)obj).id == id && obj.getClass() == getClass();
}
return false;
}
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Building JOSM with NetBeans
Frederik Ramm napsal(a): > 2. anyone got Netbeans running in a slow graphics environment and > happy with their profiling tools? I guess there is a big problem thanks to antialiasing+alpha blending, which, in remote-X environment, basically means fetching actual image bits from the display to combine them with whatever is currently being painted. You'll probably get much better performance through VNC or even maybe using NX instead of X, but there should be a way to disable all the fancy graphics stuff, or at least a way to force it do all the combinations locally. I don't recall the switches though, but NetBeans wiki can help... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Building JOSM with NetBeans
Stuart napsal(a): > Ideally, I want to develop the code in a 'normal' NetBeans project - > partly out of curiosity but also Ant seems to use a very different > mechanism and I worry that it may be a compromise in some way. So the > floor is still open for any more advice. Well, when I started with JOSM, I actually created a project from scratch and moved the sources (except the build.xml) in. My setup includes two source roots (./src and . to cover also other resources) with a short include filter (images/**,org/**,presets/**,styles/**). Then everything works perfectly (build, run, debug, even profile). I can send you a patch that would turn svn sources into full-featured NB project, if you wish. In fact, I believe it would be completely possible to have the project data in place for both the IDEs (with Eclipse using NB's generated build.xml) but I don't have Eclipse installed to test it. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] code re-use for mobile OSM?
S.B.Hawkins napsal(a): > hi there, > > i'm new to the mailing list but i'm currently working on a final year > university project involving OSM. The basis of it is getting the map displayed > on a mobile device. I wish you good luck then, being happy there's another thing that somebody does for me so I don't need to do it myself ;-) > I was hoping it would be possible to make use of some of the code involved in > JOSM? Obviously it would be made clear this was not my own intellectual > property in the project itself, would this be possible?? License-wise, you're welcome as long as you keep your project GPLv2 then. Code wise, I'm not sure you'd be able to reuse much. I expect the target platform is J2ME, right. Do you expect to store (or at least cache) maps locally? In any case, you should look at the OSM mobile API [1] (a binary protocol optimized for mobile usages where bandwidth is scarce and transfered data are far from free). > Also, i've been to > http://josm.openstreetmap.de/svn/trunk/src/org/openstreetmap/josm/ > but i'm a little unsure of where to look for what i'm after making use of. > I was hoping to make use of JOSM's ability to read the OSM files and inform > myself of how to then work with those results. Could someone point me in the > right direction?? See the OSM protocol [2] itself and make yourself familiar with OSM primitives first. The next paragraph expects you know how are the geodata represented in OSM world. Because the device resources are quite limited too, you'll need to pay special attention to data structure design that would cover use cases as effectively as possible. If map editing is not such an use case*, your data structures would end up very different from what JOSM uses as you'd optimize for rendering and routing. Forget about Node class. Maybe forget even about Way class. Class instances are too bulky for J2ME space, as any J2ME game developer would tell you. Byte/int array be your friend ;-) Forget about keeping tags in their string forms, forget about keeping most of them, anyway. *) Even if editing was an use case, I'd go with read-only optimized layer and an (initially empty) overlay with all the OSM bells and whistles. The user won't be able to author too much of the data on the road anyway. [1] http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol [2] http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] josm-ng progress
Frederik Ramm napsal(a): > Hi, > > JOSM does not upload changes in the order you made them (because this > would probably cause an unnecessary amount of uploads for various > steps of your local edit history). > > This is all fine, but every now and then uploading stops due to a > network failure or so. JOSM then clears the whole command/undo history > because logically the *changed elements* that have been uploaded are > something completely different from the *change actions* visible > there, and you have no chance to find out which actions have been > "uploaded" and which haven't (some might be partially uploaded even). Well, I can (if I try harder) make the modified state independent of undo queue clear. On every primitive upload, its modified state will be cleared so partial upload would leave the rest of primitives marked as modified and upload them correctly later. If you undo an already posted change, the undo operation could mark the primitive modified again (not currently implemented this way), so subsequent uploads would behave correctly. This would also need correct handling of the visible flag: 1. new Node (id=0, action=add) 2. Upload (Node.id = whatever server returns, action: none (!modified)) 3. Undo (mode marked modified/deleted) 4. Upload (Node marked !visible,!modified) 5. Redo (modified, visible, id still from the server) 6. Upload - can I reintroduce a deleted node through the REST API? Please note that in (3) the undo system won't physically return the data set to the state before (1). It would do a logical return - keep the node and mark it as deleted. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
[josm-dev] josm-ng progress
... is limited. Well, I have declared I have little time for the baby (have real babies to look after ;-) among other things), but I manage to make a commit from time to time. For now I concentrate on the very basics of the design, as the initial implementation was made in the mode of "do the minimum necessary to validate the concept". I'll try to summarize the architecture over the weekend but for the last two evenings, I have at least managed to put more thoughts into the undo system, updated the code to implement the idea well, and even cover it with few tests. Here is how is it meant to work. Please look at it and try to find weak points where the scheme would broke. 1) No commands. User actions perform DataSet modifications directly (through the API of DataSet and individual primitives). 2) DataSet exports UndoableEdits to a registered UndoManager (there is one per editable layer), after slight processing inside a special UndoableEditSupport. 3) Each DS/Primitive modification metod first creates an UndoableEdit of proper kind. The edit samples current value of the field to be modified and keeps it. 4) undo/redo of given edit just switches the current and saved value. The infrastructure enforces that you can't do an out-of-order undo/redo, so switch is safe. 5) To support grouping of edits, DataSet exports runAtomic(Runnable) method. Anything running inside it's run will be posted to the UndoManager as single (Compound)UndoableEdit, so you can undo/redo it atomically. 6) To support incremental edits (like if you're dragging around the selection - that modifies the DataSet on every mouse move event), runAtomic takes a token that can be compared. If you perform two (or more) consecutive runAtomic()s with the same token, all the UndoableEdits generated during the second (subsequent) round are discarded. This works thanks to 3 and 4: user action: [change x from 1 to 2| save x was 1] user action: [change x from 2 to 3|discard] user undo: [undo change - set x to 1, save x was 3] user redo: [redo change - set x to 3, save x was 1] The only thing that needs to be taken care of in such case is that you use the same token only for relevant groups of edits. The use case for this is to generate new token on mouse down, use the token throughout the whole drag (thus the complete drag operation of the node selection/way/whatever ends up being single undoable edit) and then discard the token on mouse-up. That's all the magic in there. It should cover complicated edits, composition of edits and simple undo. Is there a hole in it? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSMng prototype [resend]
Gervase Markham napsal(a): > Petr Nejedly wrote: >>> Performance isn't as good (well, it is doing more work) and I get some >> Lines wider than 1px are much more expensive to paint and the stock style >> sets 2px even to residential ways. > > I think it would be entirely reasonable to draw them narrower if the > selection area around them remained the same size. (Also, nodes could do > with being larger...) Selection would stay (once implemented, way selection is not in there yet) invariant regardless of painting style/implementation. > >>> very strange grey/orange/red "fills" over large parts of the screen >>> at certain zoom levels. I can provide screenshots and details if it >>> would help. >> >> Yes please. With data source, location and zoom level... > > czechia.osm, as given in your original email. > > - File | Open | select file | wait > - File opens, centred on Hrebec > - Using mousewheel, zoom out four or five times > - See attached screenshot > - If the coordinates change, the redraw turns that area back to black. > - Scrolling around causes the corruption to change and move, but never > to disappear; it can be grey or orange as well as yellow or pink > - Zooming in quite a bit further seems to get rid of it > > If there was a zoom level indicator, I'd tell you which ones it occurs > at :-) Hmm :-) The current zoom is printed to console, but your zoom was either 448 or 537. But generally it seems like a problem with graphics drivers or java's drawing library. The color is one of the highway colors, not any area color, so rendering of wide lines seems to be broken in specific cases. I can't reproduce the problem on my side. Could you try playing with Java2D demo ($JDK/demo/jfc/Java2D) or updating java or graphics card drivers? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSMng prototype [resend]
Gervase Markham napsal(a): > Petr Nejedly wrote: >> This worked for me (i.e. rendering was mappaint-like): >> java -classpath JOSM.jar:dist/josm-ng.jar:lib/swing-layout-1.0.3.jar >> org.openstreetmap.josmng.ui.Main > > My copy of josm.jar was too old. I just downloaded > josm-latest.jar and now it works. > > Performance isn't as good (well, it is doing more work) and I get some Lines wider than 1px are much more expensive to paint and the stock style sets 2px even to residential ways. > very strange grey/orange/red "fills" over large parts of the screen at > certain zoom levels. I can provide screenshots and details if it would help. Yes please. With data source, location and zoom level... > Redo doesn't work yet... Not implemented at all. Well, trivial addition, plumbings are in place... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSMng prototype [resend]
Gervase Markham napsal(a): > Petr Nejedly wrote: >> For running with all the mappaint bells and whistles, run: >> java -classpath /path/to/josm.jar:dist/josm-ng.jar >> org.openstreetmap.josmng.ui.Main > > To be more precise, run: > > $ ant jar > $ java -classpath > /path/to/josm.jar:dist/josm-ng.jar:lib/swing-layout-1.0.3.jar > org.openstreetmap.josmng.ui.Main > > although adding josm.jar doesn't seem to make any difference to me. I > can't get any bells and whistles :-( Well, you have to prepend it, so it hides the empty elemstyles.xml from josm-ng.jar and uses the full one from josm.jar (and icons too). This worked for me (i.e. rendering was mappaint-like): java -classpath JOSM.jar:dist/josm-ng.jar:lib/swing-layout-1.0.3.jar org.openstreetmap.josmng.ui.Main > What's the license on swing-layout-1.0.3.jar? LGPL, though I still don't really depend on it. I was just lazy to switch the form layout to something available when switching back to JDK1.5. See https://swing-layout.dev.java.net/ -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSMng prototype [resend]
Gabriel Ebner napsal(a): > You can get an account for svn.osm.org from Tom Hughes. Frederik is OK, "JOSMng" is cleaned up, GPLv2 licensed, buildable and running at http://svn.openstreetmap.org/applications/editors/josm-ng/ Just do: $ svn co http://svn.openstreetmap.org/applications/editors/josm-ng $ cd josm-ng $ ant run to get it working (Needs Java 1.5 and ant 1.6.5) I have not added style data there yet, so it runs wireframe view (which is an empty fallback style, BTW, not a separate painter implementation). For running with all the mappaint bells and whistles, run: java -classpath /path/to/josm.jar:dist/josm-ng.jar org.openstreetmap.josmng.ui.Main -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSMng prototype [resend]
Frederik Ramm napsal(a): > I'll continue working on JOSM as planned but if josm-ng looks as if it > is going to fly then I have no objections against a clean start. At the > moment I get > > Exception in thread "main" java.lang.NoClassDefFoundError: > javax/swing/GroupLayout$Group > > with Java 1.5 - do I need 1.6? No, not really. I have rebuilt current code for JDK1.5: Try http://stoupa.sh.cvut.cz/~nenik/OSMProcessor1.5.jar -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Changes to fix accidental moving
David Earl napsal(a): > If the density is so great > that you can't decide whether you're selecting and area or dragging, I > would suggest that you don't realistically know what you would select > anyway and that you would have to zoom in to get it right anyway. Exactly! What is your use case for drag-select in JOSM anyway? I haven't used it even once yet! Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] problems with saving files in JOSM
Petr Nejedly napsal(a): > Igor Brejc napsal(a): >> As I'm no expert on Java in combination with Windows, I'm wondering: >> - is this a Vista issue? > > Well, the issue is trvially and 100% reproducible even on linux: > 1. New file > 2. create two nodes (1 way) > 3. Save (enter some name) > 4. create another way (another 2 nodes) > 5. Save -> now the file is not really saved > > 6. Save as (another file name) -> thie file is saved correctly. So I have debugged it and the problem is simple. The data is saved correctly, but then the (preserved, according to my settings) backup file is copied back over the new save (as if the save had failed). The fix should be trivial... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] problems with saving files in JOSM
Igor Brejc napsal(a): > As I'm no expert on Java in combination with Windows, I'm wondering: > - is this a Vista issue? Well, the issue is trvially and 100% reproducible even on linux: 1. New file 2. create two nodes (1 way) 3. Save (enter some name) 4. create another way (another 2 nodes) 5. Save -> now the file is not really saved 6. Save as (another file name) -> thie file is saved correctly. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
