Opened 15 years ago
Closed 15 years ago
#4288 closed defect (fixed)
[PATCH] image files as parameters when starting JOSM leads to IOException
Reported by: | Cobra | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: | bomm |
Description
JOSM can open .osm and .gpx files directly when starting it and passing the file names as paramter, but when trying the same trick with geotagged images leads to this - one error window and one exception per image, all alike:
java -jar josm-latest.jar 201001*.gpx IMG_*.JPG (...) java.io.IOException: Could not import 'IMG_2582.JPG'. at org.openstreetmap.josm.io.FileImporter.importData(FileImporter.java:38) at org.openstreetmap.josm.actions.OpenFileAction.openFile(OpenFileAction.java:65) at org.openstreetmap.josm.Main.downloadFromParamString(Main.java:492) at org.openstreetmap.josm.Main.postConstructorProcessCmdLine(Main.java:381) at org.openstreetmap.josm.gui.MainApplication$2.run(MainApplication.java:175) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
josm revision is 2729
Attachments (1)
Change History (5)
comment:1 by , 15 years ago
Cc: | added |
---|---|
Summary: | image files as parameters when starting JOSM leads to IOException → image files as parameters when starting JOSM leads to IOException [analyzed] |
comment:2 by , 15 years ago
Possible, but I think there is an easier way to do it:
Collect all files from the command line into a list and then run OpenFileAction on it.
by , 15 years ago
Attachment: | patch-4288.diff added |
---|
patch to process a list of files specified as command line params
comment:3 by , 15 years ago
Summary: | image files as parameters when starting JOSM leads to IOException [analyzed] → [PATCH] image files as parameters when starting JOSM leads to IOException |
---|
uploaded a patch
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
according to the comments in FileImporter.java, a subclass has to override only one of
importData(File file) and importData(List<File> files)
JpgImporter.java overrides isBatchImporter() to return true and overrides importData(List<File> files) but not importData(File file)
OpenFileAction.java unconditionally calls importData(File file) for every importer that accepts the current file. This leads to the error messages.
One solution would be to require overriding/implementing importData(File file) even for batch importers.
For JpgImporter.java this would mean something like this:
but this is probably not correct because the GeoImageLayer should be created from all images not from a single file.
The main problem seems to be that postConstructorProcessCmdLine(Map<String, Collection<String>> args) in Main.java calls downloadFromParamString(false, s) individually for every single file which calls OpenFileAction.openFile(f). The current implementation works well when a directory name is specified instead of a set of file names.
If specifying image files on the command line is required, all file names must be added to a list before actually processing them. Unfortunately Main.java does not know that a file will be processed by a batch importer. Maybe a batch importer can handle this itself if it gets notified again after the last file.
The importer could add all files to a list as long as it accepts the file. When the importer is called with a file that is not accepted, it could process all remembered files. The importers would need a notification after the last file of the command line to process all pending files.
With this solution the JpgImporter would create the GeoImageLayer either when a a file with a different extension is specified after a set of JPEG files or when the end of the command line is reached.
If the batch importerts transparently batch their files, it might no longer be necessary to distinguish beween single-file importers and batch importers.