JOSM Not loading some building nodes

[kauevestena]

Look at version2 of ​https://www.openstreetmap.org/way/1160507128/history

What steps will reproduce the problem?

1. There's lots of examples like the one in the images above at this neighborhood:https://www.openstreetmap.org/relation/5522180#map=16/-3.7094/-38.5529

What is the expected result?

load all building nodes

What happens instead?

the too close ones that appear in iD, OSM.org, and even on JOSM history panel, just don't appear at JOSM canvas

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2023-03-30 16:51:36 +0200 (Thu, 30 Mar 2023)
Revision:18700
Build-Date:2023-03-31 01:30:56
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18700 en) Linux Ubuntu 22.04.2 LTS
Memory Usage: 225 MB / 2964 MB (113 MB allocated, but free)
Java version: 11.0.18+10-post-Ubuntu-0ubuntu122.04, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 2560×1080 (scaling 1.00×1.00) :0.1 1360×768 (scaling 1.00×1.00)
Maximum Screen Size: 2560×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: ubuntu:GNOME
Java package: openjdk-11-jre:amd64-11.0.18+10-0ubuntu1~22.04
WebStart package: icedtea-netx:all-1.8.4-1build1
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-5build1
libcommons-logging-java: libcommons-logging-java:-
fonts-noto: fonts-noto:-
VM arguments: [--patch-module=java.desktop=/usr/share/icedtea-web/javaws.jar:, --add-reads=java.base=ALL-UNNAMED,java.desktop, --add-reads=java.desktop=ALL-UNNAMED,java.naming, --add-reads=java.naming=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop, --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop, --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,jdk.jsobject, --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop, -Dicedtea-web.bin.name=javaws, -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws.sh, -Djava.security.manager, -Djava.security.policy=/etc/icedtea-web/javaws.policy]

Plugins:
+ BuildingGeneralization (36)
+ buildings_tools (36011)
+ measurement (35978)
+ reverter (36043)
+ undelete (36011)
+ utilsplugin2 (36011)

Validator rules:
+ ${HOME}/custom_dupe_nodes.validator.mapcss

Last errors/warnings:
- 00012.984 E: Skipping to the next rule, because of an error:
- 00012.988 E: org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.ParseException: Encountered " <S> " \n   "" at line 13, column 6.

[taylor.smock]

I feel like I'm missing something. What does custom_dupe_nodes.validator.mapcss look like? Does it merge duplicate nodes?

I'm not seeing the behavior that I think you are talking about.

Specifically, I am not seeing the deletion of any nodes. Can you give me specific steps to reproduce? If a specific building is the problem, you can copy its OSM id via ctrl + c. You can then paste it in the steps to reproduce.

Example steps to reproduce:

1. Download area for ​https://osm.org/relation/5522180#map=16/-3.7094/-38.5529
2. Select way 1107484204
3. Move node 10133457174
4. Upload. See node <duplicate> disappear.

[anonymous]

Well, "custom_dupe_nodes.validator.mapcss" was a try of establishing a custom node detection validator, It didn't worked, anyway the screenshots were taken before trying it out (so it mean no influence on the issue).

In the example that I gave, it just loaded 5 nodes of a feature containing actually 6 (pay attention to the JOSM selection part of the first screen shot, at right side, and then at openstreetmap.org at the left side)

But now sending other examples as simple steps to reproduce:

1. go to "Areas Around Places" and then type "pirambu ceara" it will be the only single result
2. filter by ids with the search string: "id:1160507009"
3. select their nodes, you will see 16 nodes
4. look at the same feature at openstreetmap.org: ​https://www.openstreetmap.org/way/1160507009 you will see 17 nodes there, one is missing at josm!!
5. select the way and click at "history", curiously it will say "17 nodes"

you can repeat the same steps with the following ids:

• 1160501531 (14 nodes vs 15)
• 1160504547 (10 vs 11)
• 1160503128 (10 vs 11)

this are only few samples, you can find a bunch, for example opening iD, in the surroundings with: ​https://www.openstreetmap.org/edit#map=18/-3.71162/-38.55142 (here it shows 249 warnings, and its at zoom level 18!!)

[kauevestena]

just for the record, I'd forgot to add my name

[GerdP]

Is this about counting the closing node twice or not?

[gaben]

Seems like, yes.

[skyper]

Replying to kauevestena:

the too close ones that appear in iD, OSM.org, and even on JOSM history panel, just don't appear at JOSM canvas

Seems to be a misunderstanding. In the panels JOSM only displaces the number of individual nodes while iD, osm.org, JOSM history dialog and Advanced Info show the way's node list.

[gaben]

As others have explained that this behaviour is by design and not a problem.

[taylor.smock]

Given a building with node a, node b, node c and node d, such that the building way can be represented as abcda, there are only 4 nodes.

This is why the OSM website will show 5 nodes, but JOSM will only have 4 nodes for the given way. The last node is just a method to indicate that the way is closed (in many cases, this will then indicate that the way is an area instead of a linear feature, but this is dependent upon the tagging).

Hopefully this helps explain the difference in node counts. Please take a look at ​osmwiki:Way and ​osmwiki:Area if you want a more indepth explanation of what is going on in the OSM API.