Several Bugs in ImportImagesPlugin

[ajoessen]

We have a new source for aerial photos by Aerowest. They provide a service where we get jpg with world file in EPSG 31466-31468. Importing these pictures fail only by some users, maybe only Windows systems.
Providing a .prj-file results in crash of the plugin. Maybe a sample .prj should be placed in the wiki to investigate the expected content of that file.
Using the Josm-standard Mercator projection we get no result, only wgs84 works.
But on the mentioned Windows systems, the picture gets squeezed to the right or left of the screen, as in
​http://www.tappenbeck.net/forum/osm/aero_bilder_test.jpg
Changing "Easting first" checkbox sdoes not solve the problem.

[bastiK]

I get an Image that is distorted in a similar way as ​http://www.tappenbeck.net/forum/osm/aero_bilder_test.jpg on Ubuntu. (Following the steps in ​http://forum.openstreetmap.org/viewtopic.php?pid=180578#p180578).

The following is printed to the console (probably unrelated to the issue):

loading plugin 'ImportImagePlugin' (version 26413)
Logging properties file not found. Using standard settings.
Aug 4, 2011 4:14:39 PM org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory createBackingStore
INFO: Creating cached EPSG database version 7.1.0. This operation may take a few minutes...
Aug 4, 2011 4:14:43 PM org.geotools.referencing.factory.epsg.AuthorityCodes get
WARNING: SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "WGS84(DD)"
java.sql.SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "WGS84(DD)"
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
	at org.hsqldb.jdbc.jdbcPreparedStatement.setParameter(Unknown Source)
	at org.hsqldb.jdbc.jdbcPreparedStatement.setString(Unknown Source)
	at org.geotools.referencing.factory.epsg.AuthorityCodes.getSingle(AuthorityCodes.java:202)
	at org.geotools.referencing.factory.epsg.AuthorityCodes.access$300(AuthorityCodes.java:55)
	at org.geotools.referencing.factory.epsg.AuthorityCodes$Map.get(AuthorityCodes.java:504)
	at org.geotools.referencing.factory.epsg.AuthorityCodes$Map.get(AuthorityCodes.java:479)
	at org.geotools.referencing.factory.epsg.DirectEpsgFactory.getDescriptionText(DirectEpsgFactory.java:671)
	at org.geotools.referencing.factory.BufferedAuthorityFactory.getDescriptionText(BufferedAuthorityFactory.java:343)
	at org.geotools.referencing.factory.ManyAuthoritiesFactory.getDescriptionText(ManyAuthoritiesFactory.java:698)
	at org.geotools.referencing.factory.ThreadedAuthorityFactory.getDescriptionText(ThreadedAuthorityFactory.java:333)
	at org.openstreetmap.josm.plugins.ImportImagePlugin.PluginOperations.loadCRSData(PluginOperations.java:387)
	at org.openstreetmap.josm.plugins.ImportImagePlugin.ImportImagePlugin.<init>(ImportImagePlugin.java:102)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at org.openstreetmap.josm.plugins.PluginInformation.load(PluginInformation.java:271)
	at org.openstreetmap.josm.plugins.PluginHandler.loadPlugin(PluginHandler.java:476)
	at org.openstreetmap.josm.plugins.PluginHandler.loadPlugins(PluginHandler.java:534)
	at org.openstreetmap.josm.plugins.PluginHandler.loadLatePlugins(PluginHandler.java:573)
	at org.openstreetmap.josm.gui.MainApplication.main(MainApplication.java:245)
[...]
Toolbar action without name: org.openstreetmap.josm.plugins.ImportImagePlugin.LoadImageAction
Error: NaN in greatCircleDistance
Error: NaN in greatCircleDistance
Could not find mediaLib accelerator wrapper classes. Continuing in pure Java mode.

[bastiK]

There is a new version ([o26452]). The *.prj file loading is unchanged, but it should work correctly when you keep Mercator (EPSG:3857) as editor projection and select Gauß-Krüger (EPSG:31466-31469) as source image projection from the right click menu of the image layer.

[kellerma]

Thanks a lot!
So "mercator" is now the default? => So Ticket Ticket #6655 could be closed.

Regarding "Datumskorrektur":
Is the lib Geotools able to handle so called "nadgrids" file? => this would be the best solution!
Example for germany:
​http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsb

Bye,
Frank

[bastiK]

Replying to kellerma:

Thanks a lot!
So "mercator" is now the default? => So Ticket Ticket #6655 could be closed.

done

Regarding "Datumskorrektur":
Is the lib Geotools able to handle so called "nadgrids" file? => this would be the best solution!
Example for germany:
​http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsb

JOSM supports NTv2 out of the box, but i think, Geotools does not. (They have only North American Datum Conversion grid (NADCON).) Has it been asked / investigated, what Aerowest is using in detail? If they aren't using grid file either, this would be pointless.

Description of different transformations DHDN (Deutsches Hauptdreiecksnetz) -> ETRS89:
​http://crs.bkg.bund.de/crseu/crs/eu-description.php?crs_id=dERFX0RIRE4gLyBHS18z

You seem to get sub meter accuracy by applying different 7 parameter datum conversions for North- Middle- and South Germany. I should be enough for mapping purpose.

[kellerma]

You seem to get sub meter accuracy

How do I get - as a user - these Helmert-Trafo parameters (for my specific region) into the Plugin/JOSM?

North- Middle- and South Germany

These are for West Germany and somewhat orthogonal to GK2/3/4/5 which geotools uses with always the same
saxony (1m accuracy) parameters which lead e.g. in Aachen to more than 3 m differences.

Thank you.

[bastiK]

Replying to kellerma:

You seem to get sub meter accuracy

How do I get - as a user - these Helmert-Trafo parameters (for my specific region) into the Plugin/JOSM?

I think it is not possible, at the moment: It has been reported, that the plugin does not work, when a *.prj file is provided. (But I haven't tried myself and don't know if it's easy to fix.)

North- Middle- and South Germany

These are for West Germany and somewhat orthogonal to GK2/3/4/5 which geotools uses with always the same
saxony (1m accuracy) parameters which lead e.g. in Aachen to more than 3 m differences.

Does that imply, what they write on crs.bkg.bund.de is incorrect and the "Middle" Parameter set will result in > 1m errors in Saxony?

--

Another option I see at the moment: Add support for GK in JOSM core, then use the Image without warping. GK should preserve angles, so it should be possible edit normally and to use "Q" as in EPSG:3857.

[kellerma]

.prj-files seems to work with your new version: I could successfully change e. g. "PARAMETER["false_easting", 4500000.0]" to "PARAMETER["false_easting", 4500005.0]".
Sadly, TOWGS84[...] doesn't seem to have any effect.

"bund.de" is always right ;-)
In lower saxony (Niedersachsen) you'll be inside 1m, in saxony (Sachsen, e.g. Dresden) may be not.
The "saxony parameter" (which is used by geotools for GK2/3/4/5)

TOWGS84[612.4, 77.0, 440.2, -0.054, 0.057, -2.797, 2.55]

is not listed on "bund.de" as far as I know.

[kellerma]

Oopsi, I stand corrected: It's indeed listed as "DE_RD/83 / GK_3" on "bund.de"

[kellerma]

Oopsi Oopsi:
the towgs84 work also with .prj-files.
You just to have get sure that the name doesn't match the name in geotools config ;-)
A nice enhancement would be if you have to choose just one default ".prj" and not for every single
.jpg file.
Thank you.

[bastiK]

Can you post a *.prj file and what region you are using it for?

[kellerma]

Here a working "31468.prj"-file for south germany (most of Bavaria - e. g. Nuremberg or Munich).
The only differences are

a) "- Sued" appended in the DATUM

b) the "south-germany"-TOWGS84-parameters (instead of the default saxony)

PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
  GEOGCS["DHDN",
    DATUM["Deutsches Hauptdreiecksnetz - Sued",
      SPHEROID["Bessel 1841", 6377397.155, 299.1528128, AUTHORITY["EPSG","7004"]],
        TOWGS84[597.1,71.4,412.1,0.894,0.068,-1.563,7.58], AUTHORITY["EPSG","6314"]],
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
    UNIT["degree", 0.017453292519943295],
    AXIS["Geodetic longitude", EAST],
    AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4314"]],
  PROJECTION["Transverse Mercator", AUTHORITY["EPSG","9807"]],
  PARAMETER["central_meridian", 12.0],
  PARAMETER["latitude_of_origin", 0.0],
  PARAMETER["scale_factor", 1.0],
  PARAMETER["false_easting", 4500000.0],
  PARAMETER["false_northing", 0.0],
  UNIT["m", 1.0],
  AXIS["Easting", EAST],
  AXIS["Northing", NORTH], AUTHORITY["EPSG","31468"]]

[bastiK]

Hi Frank,

Thanks for the prj file. I added GK to JOSM core (including BETA2007), so there is now an alternative method, that should give full precision (on JOSM's side):

• download JOSM >= 4314 and select Gauß-Krüger+correct zone as main projection
• use ImportImage plugin to load the .jpg
• in the popup, do not use the first button "default image projection", but choose the second option, "JOSM's main projection". Also do not change the projection from the right click menu of the image layer
• the image should load considerably faster, because it is not warped

Please test, if all works as expected!

One caveat of this method is, that you cannot really use Bing Aerial or OSM background at the same time.

It would be even nicer if the PicLayer plugin could be used:

• less error prone, because you cannot hit the wrong button (as it does not even support image warping)
• much slimmer plugin, no bulky libraries
• supports manual offset adjust

I'll look into it today, so not sure if it is worth bothering the forum with the intermediate solution (using ImportImage plugin).

Bye, Paul

[kellerma]

Hi Paul,

I already looked at it last night, looks good :)

Thanks a lot,
Frank

[bastiK]

Bugs fixed. Note: PicLayer plugin can now be used alternatively.