JOSM cannot load (some of?) its own savings

[Gingko]

What steps will reproduce the problem?

1. Import objects into JOSM.

For example this one (a single node !) loaded using Overpass API :

[out:json][timeout:25];
// gather results
node(361706);
// print results
out geom;

2. Save your contents.

File -> Save As … -> Give a name.
(for example : node361706.osm)

3. Quit and restart JOSM.

4. Reload your file.

File -> Open … -> Select the file you just saved.

What is the expected result?

Reloading the saved contents.

What happens instead?

A dialog appears telling (in French language in my case) that the file 'node361706.osm' cannot be read, because the 'version' attribute is missing from the OSM object with ID 361706 (at line 3, column 71), etc.

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

The textual contents of the 'node361706.osm' is the following:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
  <node id='361706' visible='true' lat='48.8308507' lon='2.3562364' />
</osm>

Effectively, there is no "version" attribute into this node contents (whereas it exists in some other files).
I think that JOSM should either take care of writing a version attribute everywhere it is required, or not flag this as an error.

I made a screenshot.

Revision:19412
Build-Date:2025-06-03 14:12:44

Identification: JOSM/1.5 (19412 fr) Windows 10 64-Bit
OS Build number: Windows 10 Pro 22H2 (19045)
Memory Usage: 432 MB / 24352 MB (308 MB allocated, but free)
Java version: 21.0.7+6-LTS, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: \Display0 1920x1200x32bpp@75Hz (scaling 1.00×1.00) \Display1 1920x1200x32bpp@59Hz (scaling 1.00×1.00) \Display2 1200x1920x32bpp@59Hz (scaling 1.00×1.00) \Display3 1280x1024x32bpp@60Hz (scaling 1.00×1.00)
Maximum Screen Size: 1920×1920
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: UTF-8
System property sun.jnu.encoding: Cp1252
Locale info: fr_FR
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djpackage.app-version=1.5.19412, -XX:MaxRAMPercentage=75.0, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, --add-opens=java.base/java.lang=ALL-UNNAMED, --add-opens=java.base/java.nio=ALL-UNNAMED, --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED, --add-opens=java.base/jdk.internal.ref=ALL-UNNAMED, --add-opens=java.desktop/javax.imageio.spi=ALL-UNNAMED, --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED, --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED, -Djpackage.app-path=%UserProfile%\AppData\Local\JOSM\JOSM.exe]
Dataset consistency test: No problems found

Plugins:
+ apache-commons (36438)
+ busstoptool (1.1.0)
+ fastdriveway (v1.0.1)
+ jaxb (36438)
+ mapathoner (v1.7.1)
+ mapwithai (839)
+ pmtiles (36438)
+ utilsplugin2 (36438)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/MapWithAI&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Admin_Boundaries&zip=1
- https://josm.openstreetmap.de/josmfile?page=Rules/IncompleteObjectWarnings&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransportV2&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Waterways&zip=1

Last errors/warnings:
- 00000.483 W: extended font config - overriding 'filename.Malgun_Gothic=malgun.ttf' with 'MALGUN.TTF'
- 00000.484 W: extended font config - overriding 'filename.Myanmar_Text=mmrtext.ttf' with 'MMRTEXT.TTF'
- 00000.484 W: extended font config - overriding 'filename.Mongolian_Baiti=monbaiti.ttf' with 'MONBAITI.TTF'
- 00001.134 E: java.security.KeyStoreException: Windows-ROOT not found. Cause : java.security.NoSuchAlgorithmException: Windows-ROOT KeyStore not available
- 00157.040 E: org.openstreetmap.josm.io.IllegalDataException: Attribut 'version' manquant pour l’objet OSM avec l’identifiant 361706. (à la ligne 3, colonne 71). 153 octets ont été lus. Cause : org.openstreetmap.josm.io.XmlStreamParsingException: Attribut 'version' manquant pour l’objet OSM avec l’identifiant 361706. (à la ligne 3, colonne 71). 153 octets ont été lus. Cause : org.openstreetmap.josm.io.IllegalDataException: Attribut 'version' manquant pour l’objet OSM avec l’identifiant 361706.
- 00157.131 E: Erreur - <html>Impossible de lire le fichier 'node361706.osm'.<br>Erreur :<br>Attribut 'version' manquant pour l’objet OSM avec l’identifiant 361706. (à la ligne 3, colonne 71). 153 octets ont été lus</html>

[Gingko]

Screenshot of the error message

[GerdP]

The result of the overpass query is missing the meta information, so JOSM can only save incomplete data. Unless you really don't want the meta data you should change the overpass query.

Maybe JOSM could detect the missing meta data and write the data with the tag <osm version="0.5"> instead of <osm version="0.6">
Not sure if this change allows to read the data.

[stoecker]

I think we should simply load the file and warn about it instead of not loading it...

[GerdP]

I agree. I think with other formats like o5m or pbf we don't complain at all.

[Gingko]

This makes sense, but whatever is the reason, I think it's not up to the user (especially for new users like me) to have to worry about properly requesting the information to be saved.
If the overpass query can return incomplete information, I think that JOSM should be able to handle it as it is.
Or warn about it at another level than data saving or retrieving.

[stoecker]

Replying to Gingko:

This makes sense, but whatever is the reason, I think it's not up to the user (especially for new users like me) to have to worry about properly requesting the information to be saved.
If the overpass query can return incomplete information, I think that JOSM should be able to handle it as it is.
Or warn about it at another level than data saving or retrieving.

Well. You're using an option which is only available when you select the expert mode. There is a reason why such an option is only available to experts, as you need to know how that stuff works when using it or you will get trouble like you did. JOSM protects the OSM server data integrity, but expert users are allowed to shoot themselves in the foot locally. There are use cases where such data is perfectly ok, others which will result in wasted work.

Consider this educational.

[Gingko]

Normally, expert mode means “I want to be able to do advanced things” (which I generally quickly want in any computer activity I have).
It does not mean “I want to dig into data format at the point that I need to check myself about its validity” (which would be actually a developer debug mode).
Here I requested advanced mode because it seemed to me this was the only way (or the easiest way) to request limited data concerning a large area without being overwhelmed by data that I don't need.
For example, administrative limits.

Anyway, this error tells that you consider that objects without version attribute are invalid data.
But you accept it on overpass query results, and check for this error only when loading saved data.
If they are invalid data, they should not be accepted even at the overpass query level.
Actually this may even be an overpass bug to accept to send this data without version attribute, whatever request is made about it.

[Gingko]

Hello.
After studying better the situation:
I think that a good solution could be allowing to request the missing version number (and actually all other meta attributes) on the fly, manually or automatically.
You already do something similar with incomplete relation members, with commands like "Download members", "Download with members", "Download incomplete members".
Why not having also the same kind of feature for completing missing attributes?