Modify

Opened 6 years ago

Closed 4 months ago

#14361 closed defect (fixed)

Support for image/webp for WMTS satellite imagery?

Reported by: SanderH Owned by: team
Priority: normal Milestone: 17.02
Component: Core imagery Version:
Keywords: wmts webp Cc:

Description

I'm trying to get a satellite imagery working that's available in the netherlands since a few days but don't get the WMTS version working.
Configured the WMTS imagery for this url:
https://geodata.nationaalgeoregister.nl/luchtfoto/wmts?&request=GetCapabilities&service=WMS
The provider prefers consumers to use WMTS over WMS (which is working fine) to reduce load on their servers.

When selecting the WMTS from the Imagery menu, I get a nice box to choose from the 3 projections for the 2 layers.
Whatever you choose there it won't work. JOSM keeps complaining "Could not load image file from server".

The tile properties show for example this url with http status code 200:
http://geodata.nationaalgeoregister.nl/luchtfoto/wmts?SERVICE=WMTS&REQUEST=GetTile&VERSION=1.0.0&LAYER=Actueel_ortho25&STYLE=default&FORMAT=image/webp&tileMatrixSet=EPSG:28992&tileMatrix=8&tileRow=134&tileCol=131

I noticed the default format is image/webp, which I'm unable to change to one of the known working image formats (png, png8, jpg) which is also supported for this WMTS.

Since everything else seems working OK (url does work in the browser, status code 200) the only thing I can think of is that the image format itself could be the problem.
Do you know if JOSM supports image/webp?

Can you have a look and see what's going wrong and maybe fix it accordingly if it's something JOSM can do about it?

Thanks in advance.

Attachments (0)

Change History (17)

comment:1 Changed 6 years ago by Don-vip

Keywords: wmts webp added

comment:2 Changed 6 years ago by Don-vip

WebP is not supported by the JDK, see javabug:8116096. We must make sure to use only supported formats.

comment:3 Changed 6 years ago by Don-vip

Resolution: fixed
Status: newclosed

In 11559/josm:

fix #14361 - WMTS: download only supported image formats

comment:4 Changed 3 years ago by Stereo

Resolution: fixed
Status: closedreopened

comment:5 Changed 3 years ago by Don-vip

Milestone: 17.02
Resolution: fixed
Status: reopenedclosed

In source program, coders need to put native lib files like .so/.dll/.dylib into the folder of java.library.path.

No go, sorry.

comment:6 Changed 7 months ago by anonymous

comment:7 Changed 7 months ago by Sreeram K

Resolution: fixed
Status: closedreopened

Reopening to start a discussion..

comment:8 Changed 7 months ago by taylor.smock

I'll be honest, this kind of sounds like it could be done in a plugin (and probably should be done in a plugin). I don't know if JOSM really wants to bundle a bunch of jar files it doesn't directly depend upon. The few jars I checked from TwelveMonkeys seemed to be reasonably sized (<100kb).

comment:9 Changed 6 months ago by Sreeram K <kandimalla.sreeram@…>

I made an attempt at https://github.com/ramSeraph/josm-webp-plugin , did not work. I am not very familiar with java. it almost feels like the imageio available to the imagery code was already initialised by the time the plugins load.

comment:10 in reply to:  9 Changed 6 months ago by taylor.smock

Replying to Sreeram K <kandimalla.sreeram@…>:

I made an attempt at https://github.com/ramSeraph/josm-webp-plugin , did not work. I am not very familiar with java. it almost feels like the imageio available to the imagery code was already initialised by the time the plugins load.

Notes:

  • I probably would have called it josm-imageio-extensions or something like that, and then downloaded common extensions from the maven repository (example: avif/heif in the future).
    • Use the plugin manifest Class-Path instead of packing the imageio extensions into the jar file if you do this.
    • This is more complicated. You probably don't want to do that right now.
  • To get the current plugin to build, I would do this: git mv lib/build.gradle.kts .; git mv lib/src . in the root directory of the repository.
  • Apply the following patch to get the WebP ImageIO extension registered on plugin load
    • src/main/java/org/openstreetmap/josm/plugins/webp/WebpPlugin.java

      diff --git a/src/main/java/org/openstreetmap/josm/plugins/webp/WebpPlugin.java b/src/main/java/org/openstreetmap/josm/plugins/webp/WebpPlugin.java
      index 8cc90aa..b890418 100644
      a b  
      11package org.openstreetmap.josm.plugins.webp;
      22
       3import javax.imageio.ImageIO;
      34import org.openstreetmap.josm.plugins.Plugin;
      45import org.openstreetmap.josm.plugins.PluginInformation;
      56
      public class WebpPlugin extends Plugin { 
      1112   */
      1213  public WebpPlugin(PluginInformation info) {
      1314     super(info);
       15     ImageIO.scanForPlugins();
      1416  }
      1517}

comment:11 Changed 6 months ago by Sreeram K <kandimalla.sreeram@…>

The plugin in the current form builds.. though I would definitely want to get rid of that extra sub directory structure.

And apparently the problem was not with the plugin, but with the webp layer I was testing.. I checked with another webp layer I found on the internet.. it seems to be working fine. even without the changes you suggested. I would like to debug further as to what is going wrong with the layer I am trying.

About the suggestion regarding the Class-Path and the name, would this be a prerequisite for adding it into the main plugin repository?

comment:12 in reply to:  11 Changed 6 months ago by taylor.smock

Replying to Sreeram K <kandimalla.sreeram@…>:

The plugin in the current form builds.. though I would definitely want to get rid of that extra sub directory structure.

You probably have to run gradle inside the lib directory instead of ./gradlew for your current directory structure. I generally avoid gradle just due to versioning issues.

And apparently the problem was not with the plugin, but with the webp layer I was testing.. I checked with another webp layer I found on the internet.. it seems to be working fine. even without the changes you suggested. I would like to debug further as to what is going wrong with the layer I am trying.

I don't know then -- I wasn't seeing WebP when I was stepping through the code without the scanForPlugins bit.

About the suggestion regarding the Class-Path and the name, would this be a prerequisite for adding it into the main plugin repository?

No. Using ant, however, is (just due to how the JOSM CI works). If you want to do dual ant/gradle build scripts, see the mapillary or MapWithAI plugins for examples.

If you want a very basic release CI for GitHub actions, I created one for Lanes that you can use. I should look into making it a discrete repository so that changes can be more easily propagated. Right now, the only change you should have to make is to change the default branch name from master to main in the workflow (at the time I wrote the script, I was unable to use a variable for that).

Just keep in mind that someday you may want to add additional formats (specifically AVIF, and maybe JPEG XL), and then you would either have to refactor the plugin, add another plugin, or start fiddling with different build specifications.

comment:13 Changed 6 months ago by Sreeram K <kandimalla.sreeram@…>

I will look into the options you provided and get ping back here once I am done. For now I have another problem/query.. the imagery layer I had problems with, which also happens to be the reason i attempted this plugin is hosted on Google Cloud Storage by me and looks like JOSM blacklisted all "*.googleapis.*".. this seems a bit extreme. Do you know anyway for me to override this?

comment:14 Changed 6 months ago by taylor.smock

The *.googleapis.* is actually blacklisted by the OpenStreetMap API.

See https://api.openstreetmap.org/api/0.6/capabilities (<blacklist regex=".*\.google(apis)?\..*/.*"/>).

The only suggestion I have is to set up a domain that is not google related, and use that instead. We are not going to work around the OpenStreetMap blacklist.

With that being said, feel free to open a ticket on the openstreetmap-website repository, if you feel that the blacklist is overly broad. But I don't think it will go anywhere (just due to not wanting to chance copyright issues with Google Maps).

comment:15 Changed 6 months ago by Sreeram K <kandimalla.sreeram@…>

Thanks for the pointers.. I will consider my options.

comment:16 Changed 6 months ago by Sreeram K <kandimalla.sreeram@…>

Published the plugin to the plugin wiki page. Shows up as an external plugin in the plugin list. Has been tested on windows, linux and mac. Works nicely. In the end I had to put in the scanForPlugins line. Doesn't work consistently otherwise. Thanks for all the help @taylor.smock

comment:17 Changed 4 months ago by taylor.smock

Resolution: fixed
Status: reopenedclosed

I'm going to go ahead and close this again since Sreeram released a plugin for webp.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.