Osmarender and the missing nodes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Osmarender and the missing nodes

Ed Davies-2
For a while I've noticed that using the JOSM Osmarender plugin
can result in funny lines across the map.  Since I've moved to
Firefox 2.0 it seems worse; they cause hangs rather than lines.
Batik-rasterizer reports errors with the files as well.

What's going on is that the plugin selects all of the nodes in
the screen area.  It then selects all of the segments which
start or end at any of those nodes then all of the ways which
contain any of those segments.  Consequently, the data.osm
file produced can contain segments with missing nodes (when the
segment goes from inside to outside the screen area so only one
node is present) and ways with missing segments.

Osmarender.xsl deals reasonably gracefully with ways with
missing segments (1) but it seems to assume that both nodes
referenced by each segment will be present.  This is sort of
reasonable as a segment with a missing end-point is pretty

When Osmarender.xsl tries to project a missing node the
resulting map coordinates (x and y) are not numbers so the
SVG path elements finish up with "NaN"s causing the grief.

I would suggest that the plugin be changed to include the "extra"
nodes on the far ends of segments which cross the boundary.  This
should be fairly simple, maybe something like the following
between the current node extraction and segment extraction:

    Collection<Node> extraNodes = new HashSet<Node>();
    for (Segment s: Main.ds.segments) {
        if (nodes.contains(s.from) || nodes.contains(s.to)) {
            if (!nodes.contains(s.from) && !extraNodes.contains(s.from)) {
            if (!nodes.contains(s.to) && !extraNodes.contains(s.to) {

I haven't set up the environment to try to compile this so take
it with a pinch of salt but I think it's on the right lines.

Maybe this loop can be combined with the existing loop for segments,
I've no idea what are the constraints on the order of adding to the

Ed Davies.

(1) To the extent that it deals with ways properly at all -
it rather assumes that the segments will be reasonably
ordered but that's sort of understandable, stitching together
completely unordered ways would be quite a challenge in XSLT,
particularly XSLT 1.0.  It'd be slightly easier in XSLT 2.0
but it'll probably be a while before we see that in a

(2) While looking further down OsmarenderPlugin.java I noticed
some operating system dependent code to extend the plugin
directory name to get a parameter to pass to Firefox.  Using
java.io.File.toURI would allow this to be done a lot more
cleanly and portably.  It's Java 1.4 dependent but this code
requires 1.5 anyway.

talk mailing list
[hidden email]