@RolandUnger take a look at my explanation at https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Other_maps_issues -- search for 99 and keep reading afterwards. It is possible to work around this limitation (after all, not many articles hit it), and restructure the numbering so that instead of 1..999, you have several 1..99 of different color. We simply cannot easily solve this issue at the moment with the given resources for technical reasons (and I would love to be corrected on this one)

Maintainers of projects decide which functionality (and patches) they accept and which functionality they'd consider a bad idea and refuse.
T141335#2497952 states that code contributions are welcome to fix the problem. So I don't see any reason to decline this task (as maintainers are not against support for 3 digits). The task could have lowest priority while being open though.

@Yurik, since the the map is not working properly because of the 99-limit, in it:voy we are using the old map (see https://it.wikivoyage.org/wiki/Pest#Come_orientarsi ) that show corretly all the numbers and cause no other probelm.
What we need, until this bug is fixed, is a way to show the correct number in the article (see https://it.wikivoyage.org/wiki/Pest#Altri_parchi) where is the only point where is showed the wrong number. Since is not linked to the icon constraint, it shouldn't be an issue.

It should be enough to add a new parameter to #invoke:map (e.g. extendednumbers=yes) in order to overcome the 99-limit.
This temporary patch is very quick to implement ad would avoid any discrepancy in it:voy article.
Any other alternative patch is more than welcome.

Let me know if maintainers can work on this or not, otherwise I need to remove the use of this extension, until this bug is fixed.

Thanks

@Andyrom75 are you proposing to make the number in wiki article differ from the number on the map itself?

@Yurik actually is the opposite.
The old map currently in use in it:voy shows number like 100, 101, 102, etc.
The number shown in the article (generated by the extension) are 99, 99, 99, etc.

I need that the number in the article will proceed naturally without any forced stop at 99.
This will align the number in the article with the one in the map.

See the article links that I've written in my previous message.

@Yurik, please let me know if you have understood the proposal or not.
In the second case, I'll be more than glad to explain it to you one more time.

Unitl the maintainers are not able to solve this bug, a dirty workaround is the following:

1. Use the old map (i.e. the one based on simple numeric markers) and not the new one (i.e. maki icons based one)
2. apply the following jquery patch: in MediaWiki:Common.js

$(window).load(function(){
	$(".mw-kartographer-maplink:contains('99')").each(function(){
		while( typeof $(this).attr('href').split('maplink/')[1] === "undefined" ){}
		$(this).text(parseInt($(this).attr('href').split('maplink/')[1])+1);
	});
});

This patch will correct the numbers in the article aligning them with the ones shown in the map.

Notes:

• "while loop" is necessary to wait that the extension has finished to put the wrong numbers in the article.
• "load function" avoid to start immediately the while loop

Clearly the same patch shall be applied on MediaWiki:Mobile.js in order to correct the same extension mistake opening a page on mobile view.

@Yurik, any update for the fix of this bug?

@Andyrom75 I wish I had an answer for you. It seems maki icons have gone a very different direction - they are now much better integrated into the client-side WebGL-based maps, and we might have to at some point to handle such high numbers either some other way, or figure out another solution all together. I am hopping to switch to the GL-rending at some point, but it might take some time to get there. Another solution would be for us to render custom icons, both for client and server side map generation, but then we will totally go in our own direction, which I have been trying to avoid at all costs to reduce software maintenance burden.

I understand the reason of your approach, and I agree that in a long term perspective is the right one.
Can the customized solution you mention be applied in the short term until the maki icons will manage correctly the three digits numbers?

Consider that in any case we must use a custom solution (server or client side) in order to avoid inconsistencies in our articles.

A custom solution would be best and more than 99 allowed; however, a possible work around is available, but it is rather specialized and not very intuitive for the average editor. I actually broke up the markers and used the type, group and counter parameters. My temporary test is found at https://en.wikivoyage.org/wiki/User:Matroc/Animals_of_India which is a rehash of multiple vicinity markers numbering in the hundreds as found in https://en.wikivoyage.org/wiki/United_States_National_Parks. All the POIs can be found on the geo map and mapframe
There are nuances and tricky situations that arose while I looked at this - anyhow just a thought I would add this to the conversation.

Matroc, thanks to try to find a solution to this bug/limitation that no one is willing to take in charge for its complete resolution.
In my opinion your approach would cause the creation of articles that in the future (when finally this extension would work) should be fixed and it would be difficult to find them.
The JS patch that I've mentioned above would be transparent for the editors.

Andyrom75 - I totally agree with you. We should have markers with at least 3 digits. Some of the article maps currently in Wikivoyage look terrible with so many 99 markers to say the least.
Not only would articles using my odd test approach be difficult to find when all is finally resolved later; it
would be difficult and counter intuitive for an average editor to figure out how to do this since he/she would need a deeper understanding of the templates, maps and the Kartographer extension in action.

Keeping things as simple, transparent and hidden is best.

Minor point of information: the rendered PNG directory for 1-99 and A-Z, at all icon sizes, takes 3MB of disk space so probably a comparable amount of server memory. Caching all icons from 1-999 would therefore take something like 30MB, which is completely reasonable for a long-running server process.

Tagging because we're discussing this feature—no decision yet whether we'll implement it or not.

I'm sure there are optimizations to make, but a simple approach of dropping the font size from 11px to 8px to fit the three digits looks like this in the worst-case scenario (of "small" markers):