Laurent Grenet

OK, thanks for answer. Not a real problem, since there is an easy workaround... but this is more or less a bug in the Apache commons http client and its new constructor of URL / URI....

One more "strange" behaviour that comes with this beta version : It is no more feasible to have a "|" (pipe) character in a URL. There is an easy workaround : replace it by its hexa code : "%7C" But I don't understand why this character is no more accepted, since it is accepted in the address bar of Firefox, or in URL argument of curl command. PS : This character is in particular used in Google Maps URL when we customize which elements are displayed or not, thanks to the &apistyle=... parameter

For me YES, 10 times YES, 100 times YES !

Quite perfect like this. This gives a very good answer to the problem I mentioned above. We have now a clear and robust picture regarding the mechanism of default source in both Mobac and mapevaluator and clear distinction between internal name ("name") that has to be unique, and cannot contain characters that could generate problem in some cases on one hand, and on the other hand "visible" name ("displayName") that do not have to support any constraint. Thank you so much. PS: with the fix you did...

Quite perfect like this. This gives a very good answer to the problem I mentioned above. We have now a clear and robust picture regarding the mechanism of default source in both Mobac and mapevaluator and clear distinction between internal name ("name") that has to be unique, and cannot contain characters that could generate problem in some cases on one hand, and on the other hand "visible" name ("displayName") that do not have to support any constraint. Thank you so much.

Quite perfect like this. This gives a very good answer to the problem I mentioned above. We have now a clear and robust picture regarding the mechanism of default source in both Mobac and mapevaluator and clear distinction between internal name ("name") that has to be unique, and cannot contain characters that could generate problem in some cases on one hand, and on the other hand "visible" name ("displayName") that do not have to support any constraint. Thank you so much.

Quite perfect like this. This gives a very good answer to the problem I mentioned above. We have now a clear and robust picture regarding the mechanism of default source in both Mobac and mapevaluator and clear distinction between internal name ("name") that has to be unique, and cannot contain characters that could generate problem in some cases on one hand, and "logical" name ("displayName") that do not have to support any constraint. Thank you so much.

Hi Robert, why not, but I'm a little bit surprised (and disappointed) with such a decision. It seemed to me that it was good policy to clearly separate internal naming (the "name") and external (displayed in GUI) naming (the "displayName"). Moreover, you present the "displayName" as it is something new, that is not the case. In rev 2.2.3.1 (May 2022, I do not have kept older ones), it was already there. And in "Debug/Show All Map Sources Names", both name AND displayName are shown. And the drawback...