New Styles Parameter. Refactoring the project.

[telemaxx]

Discussion for styles option.

See PR63

See PR65

See PR66

[telemaxx]

hi @nono303 : today i have played with the styles and had some problems:

• when i start via command line i got an error

2024-06-30 12:02:19.227 main@MapsforgeConfig:67 - Unrecognized option: -m D:\BTSync\oruxmaps\mapfiles\Germany_North_oam.osm.map

are the commandline parameters are not working anymore?
only via server.properties?
this would be a "breaking change", or do i miss something?

• when i start the app w/o parameter i get:

2024-06-30 12:11:10.616 main@MapsforgeConfig:67 - Missing required option: c
usage: mapsforgesrv
 -c,--config <arg>   Config directory including at least server.properties, jetty.xml, styles/default.properties

next i configure server properties and adjusted the pathes.
and i started with the argument:
"-c C:\Users\top\git\mapsforgesrv\config"

2024-06-30 12:16:29.752 main@MapsforgeConfig:105 - ################## SERVER CONFIG ##################
2024-06-30 12:16:29.760 main@MapsforgeConfig:186 - Map file(s)               : defined [{D:\mapsforgesrv\maps\Germany-North_oam.osm.map}]
2024-06-30 12:16:29.761 main@PropertiesParser:188 - Preferred map language    : defined [en]
2024-06-30 12:16:29.765 main@PropertiesParser:114 - DEM folder                : exiting - 'D:/mapsforgesrv/dem/dtm-srtm1' not a folder

map folder is ok. but DEM is not.
i think the separator / must be converted to a backslash.
for maps this is done.
@nono303 have you tested this on windows?

when i outcommenting the DEM line i got the same with the theme file.

2024-06-30 12:20:27.016 main@PropertiesParser:114 - Theme file : exiting - 'D:/mapsforgesrv/themes/active/active RT5.xml' not a file

my server.properties:

# server configuration file to be at root of 'config directory' specified with arg -c
# 'config directory' maybe be absolute or relative to user.dir
# value might be quoted
# file path must use slash (and not backslash) even on Windows system

renderer=database
# https://ftp.gwdg.de/pub/misc/openstreetmap/openandromaps/mapsV5/
mapfiles=D:/mapsforgesrv/maps
language=en
# https://drive.google.com/drive/folders/0BxphPoRgwhnoWkRoTFhMbTM3RDA?resourcekey=0-wRe5bWl96pwvQ9tAfI9cQg
# demfolder=D:/mapsforgesrv/dem/dtm-srtm1
outofrange_tms=https://a.tile.openstreetmap.fr/osmfr/{z}/{x}/{y}.png
worldmap=true
cache-control=2592000
# https://eclipse.dev/jetty/javadoc/jetty-11/org/eclipse/jetty/server/CustomRequestLog.html
requestlog-format=%{yyyy-MM-dd_HH:mm:ss.SSS ZZZ|CET}t %{client}a %{ms}T '%r' %s %O '%{User-Agent}i'

[nono303]

Hi @telemaxx
Thx for your feedback !

1. Concerning param configuration, as mentioned

configuration had changed: All must be done by files with only -c arg defining the root 'config directory'

See https://github.com/nono303/mapsforgesrv/blob/styles/HOWTO.md#configure &
https://github.com/nono303/mapsforgesrv/blob/styles/build.gradle#L84
Personally, I didn’t see that as a breaking change as args params must just be set in files and for sure, many style feature will not work with args params

2. Yes I’ve tested and run it under windows.
   https://github.com/nono303/mapsforgesrv/blob/styles/config/server.properties is the file i currently use for my own, which works fine with DEM defined with '/' (but logged with '\' at startup)

Fyi, my startup log according to my fork config

[telemaxx]

i tried 1h to get it running.
holy moly is this complicate.

I had a lot of browser windows open, file explorers and so on.

• getting the styles from internet and storing on disk
  in my case D:\mapsforgesrv

• adjusting the properties files
  At the moment i fight with the tapiola style
  in my case C:\Users\top\git\mapsforgesrv\config

i was always searching the correct window ... ;-)

i tried to rename the properties file to tapiola.properties.disabled
but still get an exception. how to disable?

i think for most users to complicate.

one big problem i see with the TCL script from @JFritzle
it uses the command line parameter.

What do you think?

[JFritzle]

IllegalStateException is caused by Java runtime versions < 21.
Virtual threads have been introduced with Java version 21.

To avoid exception, as a workaround first replace MapsforgeSrv.java file lines

if(!((QueuedThreadPool)server.getThreadPool()).getVirtualThreadsExecutor().equals(null))
	logger.info("Virtual threads are enabled");

by

String javaVersion = System.getProperty("java.version");
int dot = javaVersion.indexOf(".");
if(dot != -1) { javaVersion = javaVersion.substring(0, dot); }
if(Integer.parseInt(javaVersion) >= 21) {
	if(!((QueuedThreadPool)server.getThreadPool()).getVirtualThreadsExecutor().equals(null))
		logger.info("Virtual threads are enabled");
}

and second, from your personal jetty-threadpool-virtual.xml file delete lines

<Call class="java.lang.Thread" name="ofVirtual">
  ...
</Call>
<Call name="setVirtualThreadsExecutor">
  ...
</Call>

Don't know about side effects, but server build and runnng with Java JDK 11.0.18 starts without errors and serves valid tiles.

[nono303]

Hi @JFritzle
As I (too) quickly wrote #59 (comment)

• Jetty is now configured based on a single and standard xml file
• enabled Virtual threads JRE >= 21 only

so, just replace jetty-threadpool-virtual.xml by jetty-threadpool.xml for JRE11

[JFritzle]

Testing with original and unmodified java file MapsforgeSrv.java from @nono303 repo, using JRE 11 and not checking Java runtime version in Java code ...

Test 1:
Removed file jetty-threadpool-virtual.xml from config folder and inserted jetty-threadpool.xml instead. Got exception Exception in thread "main" java.nio.file.NoSuchFileException: C:\Program Files\cygwin\home\j\config\jetty-threadpool-virtual.xml

Test 2:
Then renamed file jetty-threadpool.xml to jetty-threadpool-virtual.xml in config folder. Got exception

Exception in thread "main" java.lang.NullPointerException
        at com.telemaxx.mapsforgesrv.MapsforgeSrv.<init>(MapsforgeSrv.java:99)
        at com.telemaxx.mapsforgesrv.MapsforgeSrv.main(MapsforgeSrv.java:130)

Test 3:
Then encapsulated MapsforgeSrv.java lines

if(!((QueuedThreadPool)server.getThreadPool()).getVirtualThreadsExecutor().equals(null))
	logger.info("Virtual threads are enabled");

by try and error

try {
   ...
} catch (NullPointerException e) {
	logger.info("Virtual threads are disabled");
};

--> No more exception, no more error. Seems, java code compiled with JDK 11 has to be modified in order to run with JRE 11.

[JFritzle]

I think it could be possible to expand the TCL scripts to handle the refactored server using several configuration files too.
Minimum requirements:

• the version string is compatible with previous server versions
• the server version can be queried without configuration using command line parameter -h as before
• querying the server version writes the version string to stdout and ends with return code 0 as before
• one single server must be able to be configured to run following rendering threads concurrently:
  At least one thread with one or more user-defined map files,
  one additional thread with the built-in world map only and without themes/styles, required for hill shading as overlay
• one single server must be able to be configured to run one single thread with the built-in world map only and without themes/styles, required for hill shading as overlay to map tiles downloaded from external sources

But neither of these requirements seem to be realized yet. At least, I didn't figure out how.

[telemaxx]

good points @JFritzle

would be cool to implement the new version of @nono303 .
it has many cleanups and new versions of the tools.

[JFritzle]

I have 2 property files: default.property & elevate.property. Server started without errors.
Could not find out how to get tile x=0,y=0,z=0 from subtasks default.property or elevate.property.
Tried http://localhost:8486/elevate/0/0/0
Got:

HTTP ERROR 500 NumberFormatException: Cannot parse null string
URI:	/elevate/0/0/0
STATUS:	500
MESSAGE:	NumberFormatException: Cannot parse null string
SERVLET:	-
[Powered by Jetty:// 11.0.21](https://eclipse.org/jetty) 

Neither
http://localhost:8486/elevate/0/0/0
http://localhost:8486/elevate.property/0/0/0
http://localhost:8486/style.property/0/0/0
http://localhost:8486/style.elevate.property/0/0/0
http://localhost:8486/style/elevate/0/0/0
was working. Query string seems to be nowhere documented.

Update:
I found the valid query string myself: http://localhost:8486/0/0/0.png?style=elevate
although the error message HTTP ERROR 500 NumberFormatException: Cannot parse null string was not really helpful!

[nono303]

Hi @JFritzle
As I (too) quickly wrote #59 (comment)

• usage had not changed: no functional regression
  just adding a new optional url parameter 'style'

[nono303]

although the error message HTTP ERROR 500 NumberFormatException: Cannot parse null string was not really helpful!

there are effectively some exceptions that might be caught and treated with correct response / message (independently of the styles PR...)
Like the other one is when you close the browser tab with tile rendering in progress...)

[nono303]

Hi @JFritzle @telemaxx
note that #66 is actually not well documented as it's a PR and not a RC

• changes are mentioned and not explained here: [FR]: Multiple theme rendering #59 (comment)
• usage is quickly described here: https://github.com/telemaxx/mapsforgesrv/blob/styles/HOWTO.md

[JFritzle]

I am currently working on recently cloned @nono303 styles project.

What I have essentially done and successfully tested so far:

• Re-introduces missing command line parameter -h respectively --help in order to query server version with exit code 0
• Initialize value FILECONFIG_JETTY_THREADPOOL = "jetty-threadpool.xml"; and use file jetty-threadpool.xml for JRE < 21. To enable virtual threads, simply rename file jetty-threadpool-virtual.xml to jetty-threadpool.xml
• Encapsulate MapsforgeSrv.java lines

  if(!((QueuedThreadPool)server.getThreadPool()).getVirtualThreadsExecutor().equals(null))
  	logger.info("Virtual threads are enabled");
  

  by try and error

  try {
     ...
  } catch (NullPointerException e) {
  	logger.info("Virtual threads are disabled");
  };
  

• Add missing check for file FILECONFIG_JETTY_THREADPOOL existence.
• Make project more general: rename [sS]tyle(s) to [tT]ask(s) where applicable. One single modified server does not only serve tiles with different themes/styles, but can be used to compare tiles from different maps (OpenAndroMaps, Freizeitkarte, ...), to compare maps in different languages, to compare maps with and without hillshading, to serve tiles with hillshading only to be used as overlay, ...
  This includes renaming of Java code variables, comments, renaming Java classes/files, renaming config folder's subfolder styles to tasks. URL request parameter style was renamed to task too, tile request URL changed from http://localhost:port/z/x/y.png?style=name to http://localhost:port/z/x/y.png?task=name
• For generalization, parameters mapfiles, worldmap, language, demfolder and renderer were moved from server.properties file to <task>.properties files and from MapsforgeConfig.java file to now named MapsforgeTaskConfig.java file
• Files in tasks subfolder not ending with file extension .properties are now ignored
• Built-in world map is now automatically enabled for task, if map definition by parameter mapfiles in task properties is missing or empty. Thus, task configuration becomes valid whether map is explicitly defined or not
• Assign default file extension to tile for missing file extension in tile request
• Log invalid tile requests
• Minor typos were corrected
• Minor code/output beautifications were applied

Update
Current development has been uploaded to my styles branch.
Subfolder dist of branch contains mapsforgesrv-fatjar.jar compiled with JDK 11 and working with JRE 11.

Above screenshot was taken from QMS using 2 server task files: elevate.properties and hillshading.properties
and 2 hardcoded QMS onlinemaps files: MapsforgeTask.tms and MapsforgeTask.hillshading.tms
tasks.zip
Onlinemaps.zip

[nono303]

🤘
Definitively need to harmonize JRE versions for this project (cf. #30)...
Will be in my annual climbing break until end of September but after, fully available to discuss and find solution to manage this 😎

[JFritzle]

Switching server configuration from command line parameters to 1 ore more task properties files, I thought it made sense to watch config folder for new task properties files, for removed task properties files and for modified task properties files in order to reflect these changes in the running server. This will allow my script based GUIs (in the future) to alter configuration parameters without need to stop and restart server.

Issue solved:
In my tests I have noticed, that logger output MAPS INFO, THEME STYLE and THEME OVERLAYS in class MapsforgeTaskHandler of one task may get mixed with logger output of a different task. This is due to enabling all task handlers successively in a MapsforgeHandler loop while logger output THEME OVERLAYS happens asynchronously in a separate thread within XmlRenderThemeMenuCallback callBack. To make sure that next task does not get enabled before THEME OVERLAYS logger output of previous task is complete, I synchronized tasks startup using a CountDownLatch and solved issue.

Issue not solved:
When setting parameter terminate=true in server.properties file, server can be stopped with URL http://127.0.0.1:8486/terminate.
Server process ends and logger writes such lines to output:

2024-09-05 16:25:26.394 JettyShutdownThread@Server:479 - Stopped Server@327bcebd{STOPPING}[11.0.23,sto=5000]
2024-09-05 16:25:26.396 JettyShutdownThread@Server:135 - Shutdown Server@327bcebd{STOPPING}[11.0.23,sto=5000]
2024-09-05 16:25:31.417 JettyShutdownThread@AbstractConnector:431 - Stopped ServerConnector@5afa3c9{HTTP/1.1, (http/1.1, h2c)}{0.0.0.0:8486}
2024-09-05 16:25:32.445 JettyShutdownThread@QueuedThreadPool:287 - Couldn't stop Thread[qtp1223867739-33,5,main]

I am bothered by the last line of output, because to endusers it looks like an uncaught error condition.
According to discussion Jetty QueuedThreadPool warnings in logs it's easy to suppress in log configuration. Unfortunately, it does not tell how. Any idea?

Update: Issue solved.

[JFritzle]

Performance comparison between "jetty-threadpool.xml" and "jetty-threadpool-virtual.xml"

Test scenario:

• OAM Germany
• Elevate theme
• Hiking style
• No logging of server requests
• Rendering 1590 map tiles (x range 8484...8589, y range 5585...5599, zoom 14)
• Rendering 1590 hillshading overlay tiles
• Downloading whole tile range by 1 single "curl" instance
• Using JAR compiled using Java code from my current styles branch

Test case 1:

• Compiler JDK 11
• Runtime JRE 11
• Jetty threadpool "jetty-threadpool.xml"
• Average request processing time for 1 map tile = 13.7 ms
• Average request processing time for 1 hillshading tile = 35.4 ms

Test case 2:

• Compiler JDK 11
• Runtime JRE 22
• Jetty threadpool "jetty-threadpool-virtual.xml"
• Average request processing time for 1 map tile = 13.7 ms
• Average request processing time for 1 hillshading tile = 35.4 ms

Test case 3:

• Compiler JDK 21
• Runtime JRE 22
• Jetty threadpool "jetty-threadpool-virtual.xml"
• Average request processing time for 1 map tile = 13.5 ms
• Average request processing time for 1 hillshading tile = 36.7 ms

Conclusion:
Test results may vary slightly by about one or less milliseconds (approximately 1%) between different test runs.
Seems there is no advantage to prefer virtual jetty threadpool over classic jetty threadpool. Or have I missed something?
I suggest to simply use threadpool "jetty-threadpool.xml" and not to distinguish between JRE versions. Do you agree?

[telemaxx]

I suggest to simply use threadpool "jetty-threadpool.xml" and not to distinguish between JRE versions. Do you agree?

Yes, i would prefer "keep it simple"

@JFritzle @nono303

[nono303]

⏩ 9ad95b1

@nono303 #79 (comment)

3 line to improve compatibility with recent version might not be a problem unless if it causes trouble on your use-case

@JFritzle #79 (comment)

_Concerning virtual threads, 3 lines to improve compatibility with recent version will not cause any problems on my side.

[JFritzle]

@nono303
To avoid need of providing external jetty XML files by users, it were very nice and comfortable, if

1. jetty XML files are read by default from assets (low priority)
2. jetty XML files can be overwritten on demand by external XML files (higher priority)
3. some elementary jetty parameters (host, port, acceptQueueSize, ...) can be overwritten via config/server.properties file (highest priority)

[JFritzle]

I have currently implemented and pushed

1. jetty XML files are read by default from assets folder (low priority)
2. jetty XML files are overridden by external XML files from config folder (higher priority)

At @nono303:

• Furtheron, to improve compatibility with recent version file FILECONFIG_JETTY_THREADPOOL_VR is now read for JRE >= 21, either from config folder or from assets folder
• I was unable to programmatically override elementary jetty parameters read from jetty.xml. Please assist!

[JFritzle]

@telemaxx @nono303

• jetty property values read from jetty.xml can now be overridden by equally named properties from file server.properties in config folder.
• If jetty configuration from assets folder is suitable, no more external jetty configuration file(s) need to be provided for the server.
  This will certainly be the standard use case.

[nono303]

U may have a look at styles...nono303:mapsforgesrv:styles
⏩ just tell me if I PR my branch it or if U prefer to directly "pick-up" some commit individually

[telemaxx]

PR would be good

[JFritzle]

@nono303

I have set up a new branch snapshot in my fork.
In that branch, I essentially merged

• recent code from my development branch tasks, which still refers to Mapsforge 0.21.0
• recent gradle version and gradle.build from your your branch 0.22, which refers to Mapsforge 0.22.0 on github
• your implementation of new asymmetric hillshading algorithms introduced with Mapsforge 0.22.0
• internally correcting hillshading MagnitudeScaleFactor by factor 0.5, as Mapsforge 0.22.0 has doubled it's default value
• adaptations to changed hillshading bitmap contents by Mapsforge 0.22.0
• new internal Mapsforge themes MOTORIDER and MOTORIDER_DARK

@telemaxx, @nono303

• I have adapted all my scripts to deal with JAR from branch tasks as well as with JAR from branch snapshot
• New scripts have been uploaded to github repos
• Using JAR from branch snapshot, new Mapsforge 0.22.0 features will be activated and selectable within scripts

[nono303]

Hi @JFritzle,
Many Thx for all this works!
I've just rebased my fork on your snapshot

my specifics

• accord log date format between log4j & jetty + improve readability of requestlog-format
• disable JavaLanguageVersion.of(11)
• + DTM1
• + tiramisu.properties

might be fixed:

• catch IllegalStateException with a warn message
• gradle 8.11

to be discussed :

• rm elevate_without_hillshading.properties as it can be done with param 'hillshading=0'
• rm duplicated hillshading_simple.properties as symlink works
• global refactor or properties + move all hillshade links from properties to README.md

[JFritzle]

Got fixed and committed:

• Caught IllegalStateException with a warn message
• Raised gradle including gradle-wrapper.jar to 8.11.1 in each of my repos

[JFritzle]

About log4j & jetty output patterns:

1. Sure, your specified log4j & jetty output patterns suite together ...

[SRV] [2024-11-25 15:42:32.111] RenderThemeFuture-Map@MapsforgeTaskHandler:271 - Enabled   : elv-background-h    --> [A] Kartenhintergrund
[SRV] [2024-11-25 15:42:32.112] main@MapsforgeTaskHandler:307 - --------------------------------------------------
[SRV] [2024-11-25 15:42:32.167] main@Server:384 - jetty-11.0.24; built: 2024-08-26T18:11:22.448Z; git: 5dfc59a691b748796f922208956bd1f2794bcd16; jvm 11.0.25+9-adhoc..jdk11u
[SRV] [2024-11-25 15:42:32.355] main@AbstractConnector:376 - Started ServerConnector@1c39680d{HTTP/1.1, (http/1.1, h2c)}{localhost:60815}
[SRV] [2024-11-25 15:42:32.393] main@Server:439 - Started Server@7749bf93{STARTING}[11.0.24,sto=0] @2024ms
[SRV] [2024-11-25 15:42:32.400] main@MapsforgeSrv:197 - Started QueuedThreadPool[qtp480490520]@1ca3b418{STARTED,8<=8<=200,i=5,r=-1,t=59930ms,q=0}[ReservedThreadExecutor@3ed242a4{reserved=0/4,pending=0}]
[SRV] [2024-11-25 15:42:35.311] qtp480490520-25@request:57 - [2024-11-25 14:42:32.540] 200	2770	12714	/0/0/0.png?task=Map
[SRV] [2024-11-25 15:42:45.187] qtp480490520-21@request:57 - [2024-11-25 14:42:44.182] 200	1005	26787	/13/4303/2703.png?task=Hillshading
[SRV] [2024-11-25 15:42:45.151] qtp480490520-22@request:57 - [2024-11-25 14:42:44.185] 200	966	29823	/13/4304/2703.png?task=Hillshading

... but I wonder if common users (not developers!) are really interested in these deep details: threads, procedure names and source line numbers.

2. In my opinion, log4j & jetty output patterns generated by my scripts are easier to read for users:
   log4j: ConversionPattern="%d{yyyy-MM-dd HH:mm:ss.SSS} %m%n"
   jetty: requestlog-format="From %{client}a Get %U%q Status %s Size %O bytes Time %{ms}T ms"

[SRV] 2024-11-25 15:55:21.942 Enabled   : elv-background-h    --> [A] Kartenhintergrund
[SRV] 2024-11-25 15:55:21.942 --------------------------------------------------
[SRV] 2024-11-25 15:55:22.026 jetty-11.0.24; built: 2024-08-26T18:11:22.448Z; git: 5dfc59a691b748796f922208956bd1f2794bcd16; jvm 11.0.25+9-adhoc..jdk11u
[SRV] 2024-11-25 15:55:22.159 Started ServerConnector@1cd629b3{HTTP/1.1, (http/1.1, h2c)}{localhost:60815}
[SRV] 2024-11-25 15:55:22.190 Started Server@332796d3{STARTING}[11.0.24,sto=0] @1873ms
[SRV] 2024-11-25 15:55:22.191 Started QueuedThreadPool[qtp1265900909]@4b741d6d{STARTED,8<=8<=200,i=5,r=-1,t=59942ms,q=0}[ReservedThreadExecutor@6986bbaf{reserved=0/4,pending=0}]
[SRV] 2024-11-25 15:55:28.233 From 127.0.0.1 Get /13/4301/2700.png?task=Hillshading Status 200 Size 31016 bytes Time 978 ms
[SRV] 2024-11-25 15:55:28.294 From 127.0.0.1 Get /13/4302/2700.png?task=Hillshading Status 200 Size 29406 bytes Time 1035 ms
[SRV] 2024-11-25 15:55:28.318 From 127.0.0.1 Get /13/4301/2700.png?task=Map Status 200 Size 48639 bytes Time 1057 ms

3. In addition, lovingly aligned output columns of task properties appear disturbed by your log4j conversion pattern:

[SRV] [2024-11-25 16:06:59.546] watchConfig@MapsforgeTaskConfig:126 - ################ TASK 'Hillshading' PROPERTIES ################
[SRV] [2024-11-25 16:06:59.547] watchConfig@MapsforgeTaskConfig:120 - Map file(s)               : default [undefined]
[SRV] [2024-11-25 16:06:59.548] watchConfig@PropertiesParser:215 - Append built-in world map : defined [true]
[SRV] [2024-11-25 16:06:59.548] watchConfig@PropertiesParser:201 - Preferred map language    : default [null]
[SRV] [2024-11-25 16:06:59.555] watchConfig@MapsforgeTaskConfig:54 - Theme file                : default [OSMARENDER]
[SRV] [2024-11-25 16:06:59.555] watchConfig@PropertiesParser:201 - Theme style               : default [null]
[SRV] [2024-11-25 16:06:59.556] watchConfig@MapsforgeTaskConfig:73 - Theme overlay(s)          : default [undefined]
[SRV] [2024-11-25 16:06:59.559] watchConfig@PropertiesParser:245 - DEM folder                : defined [D:\Landkarten\DEM\Hgt3]
[SRV] [2024-11-25 16:06:59.591] watchConfig@MapsforgeTaskConfig:207 - Hillshading algorithm     : defined [diffuselight(heightAngle: 50)]
[SRV] [2024-11-25 16:06:59.592] watchConfig@PropertiesParser:175 - Hillshading magnitude     : defined [1.5]
[SRV] [2024-11-25 16:06:59.592] watchConfig@PropertiesParser:182 - Contrast stretch          : default [0]
[SRV] [2024-11-25 16:06:59.592] watchConfig@PropertiesParser:182 - Gamma correction          : default [1.0]

-> So I suggest to provide configuration templates and built-in defaults handy for users rather than for developers. Could you agree?

[nono303]

built-in defaults handy for users rather than for developers

I agree! my fork is your takeaway ;)
don't hesitate if I need to detail my commits but pick-up all what you think interesting to merge (as-it or with your own end-user constraints, formalism, etc...) and trash others
I'll deal with rebasing on my side but at this point - with too many branches in my point of view (master, tasks, snapshot, j8 & forced j11...) - will not PR anymore to avoid confusion

[JFritzle]

As I already suggested to @telemaxx:

• Release a final and definitive version 0.21.4 of the old server type for Java 8 and Java 11, do no further development on it.
  Branches master and java8 can get removed after some grace period.
  In case of emergency, they could still get restored as long as their release is still published.
• Communicate end of life of old server type to users.
• Drop support of Java 8 and require at least Java 11.

-> Only two active branches will remain in my fork:

• branch tasks which will become my default branch, where I do PRs and where releases could be made from
  Currently, branch tasks is based on Mapsforge 0.21.0. It will become based on Mapsforge 0.22.0 as soon as it is available at Maven repo.
• branch snapshot which contains current development

[nono303]

branch snapshot which contains current development

<fussy>as snapshot refer more to a bundle at a given state, dev or unstable would be a better name for your development branch</fussy>

[nono303]

Hi @telemaxx @JFritzle
Fyi, mapsforge 0.23 had been released.
Here are the change nono303@1c545f3 for mapsforgesrv
Seems there is a BIG improvement concerning hillshading performance 🤩🤩🤩

time in ms, same runtime context (JRE, hardware, maps, hgt, algorithm & params...)

0.22

1077	/14/8687/5768.png?task=nono
1419	/14/8689/5770.png?task=nono
335	/14/8691/5769.png?task=nono
590	/14/8691/5768.png?task=nono
873	/14/8687/5770.png?task=nono
1157	/14/8687/5767.png?task=nono
1419	/14/8690/5770.png?task=nono
258	/14/8691/5767.png?task=nono
546	/14/8686/5769.png?task=nono
817	/14/8688/5771.png?task=nono
1065	/14/8686/5768.png?task=nono
1351	/14/8689/5771.png?task=nono
525	/14/8687/5771.png?task=nono
800	/14/8686/5767.png?task=nono
1086	/14/8690/5771.png?task=nono
1342	/14/8691/5770.png?task=nono

0.23

19      /14/8530/5881.png?task=nono
26      /14/8530/5877.png?task=nono
13      /14/8531/5881.png?task=nono
26      /14/8530/5878.png?task=nono
20      /14/8531/5877.png?task=nono
28      /14/8531/5878.png?task=nono
24      /14/8532/5878.png?task=nono
21      /14/8533/5878.png?task=nono
19      /14/8534/5878.png?task=nono
15      /14/8532/5881.png?task=nono
18      /14/8532/5877.png?task=nono
18      /14/8533/5881.png?task=nono
21      /14/8533/5877.png?task=nono
20      /14/8534/5877.png?task=nono
20      /14/8534/5881.png?task=nono

[JFritzle]

I have adopted your changes and tested them myself:
Wow! Very impressive improvement! Fantastic!
Changes are already committed to my github repo.

[nono303]

Hi @telemaxx @JFritzle
I Was looking at changes of mapsforge 0.23 and see an Adaptive hill shading which was not present on 0.22.
Just have a quick & easy implementation of "adaptasy" nono303@8910100 and once again, results are promising both in terms of quality and speed.

Out last discussion concluded that given the difference in quality and speed between simple and Clear Asymmetric, simple remained the privileged one.
But with this new adaptative implementation of clear asymmetric in HiRes mode, this is no longer the case.

1. Speed

adaptasy & simple rendering time are quite the same at zoom level > 12 but when you move away, it change a lot!
ex. At zoom level 7:

2103    /7/68/44.png?task=hs_simple
2075    /7/65/45.png?task=hs_simple
1606    /7/65/42.png?task=hs_simple
2269    /7/68/43.png?task=hs_simple
2020    /7/68/45.png?task=hs_simple
2102    /7/64/44.png?task=hs_simple
1907    /7/68/42.png?task=hs_simple
2595    /7/64/43.png?task=hs_simple
2229    /7/66/46.png?task=hs_simple
2047    /7/67/46.png?task=hs_simple
1919    /7/64/45.png?task=hs_simple
2146    /7/65/46.png?task=hs_simple
1659    /7/64/42.png?task=hs_simple
1573    /7/68/46.png?task=hs_simple
1577    /7/64/46.png?task=hs_simple
12      /7/68/44.png?task=hs_adaptasy
13      /7/65/45.png?task=hs_adaptasy
11      /7/68/43.png?task=hs_adaptasy
11      /7/65/42.png?task=hs_adaptasy
15      /7/68/45.png?task=hs_adaptasy
15      /7/64/44.png?task=hs_adaptasy
14      /7/64/43.png?task=hs_adaptasy
15      /7/68/42.png?task=hs_adaptasy
13      /7/66/46.png?task=hs_adaptasy
15      /7/67/46.png?task=hs_adaptasy
14      /7/64/45.png?task=hs_adaptasy
13      /7/65/46.png?task=hs_adaptasy
12      /7/64/42.png?task=hs_adaptasy
10      /7/68/46.png?task=hs_adaptasy
16      /7/64/46.png?task=hs_adaptasy

2. Quality

I've visually benched adaptasy & simple in standalone grayed and in OAM overlayed with my theme.
Here are the zoom levels results in grayed mode (left adaptasy, right simple)

z7

z13

z16

3. Fine tuning against default

maxSlope (100 left, 80 right)

asymmetryFactor (0.9 left, 0.5 right)

My conclusion was to move all hillshading-algorithm to adaptasy(0.8,0,100,16,16,true)

@JFritzle note that 3 new static hardcoded params had been defined as I don't see the point in my case to externalize them in properties file...

[JFritzle]

Mission accomplished.

[telemaxx]

Mission accomplished.

Dito, release created.

[JFritzle]

@nono303

Server version 0.23.0.2 now in branch tasks:

• Replaced fixed HILLSHADING_ADAPTIVE_ZOOM_ENABLED = true; by HILLSHADING_ADAPTIVE_ZOOM_ENABLED = false;
  to allow the user himself adjust hillshading zoom levels.
• Introduced 2 new optional parameters hillshading-zoom-min and hillshading-zoom-max instead.
• If an optional parameter is unset, theme's built-in zoom level or Mapsforge's default zoom level is used.
• An optional zoom level is only applied to theme, if hillshading is enabled in theme at all.