I think the disabling of the Wikivoyage nearby feature is proved a failure. The usage of this feature should be controlled by the community itself which can be done easily in MediaWiki:Kartographer.js and by adding a variable to the map object which can be analyzed before calling wvmap.nearby(). The were discussion on several pages (https://de.wikivoyage.org/wiki/Wikivoyage:Lounge/Archiv_2022-12-31#Karte_mit_den_Wikivoyage_-_Artikeln? , https://de.wikivoyage.org/wiki/Wikivoyage:L%C3%B6schantr%C3%A4ge/Wikivoyage:Artikel%C3%BCbersicht ) asking to keep the Wikivoyage nearby feature at least for a map showing all articles. In my view, the disabling of Wikivoyage nearby would meet with a refusal in other Wikivoyage branches, too.

I made several tests. The usage of leaflets prune clusters (as used by Wikivoyage nearby) is the fastest and most convenient solution to present about 30.000 markers. This cannot fastly be done with mapframe and GeoJson, and the clustering of markers is not working. I know that the (manual) update of articles lists needed is not a favored solution but up to now I have no better idea.

That's why I ask you to remove the false value for wgKartographerWikivoyageNearby for the German Wikivoyage (see https://noc.wikimedia.org/conf/InitialiseSettings.php.txt ).

There is another problem: within a location like a town there are on Wikivoyage usually no other sites with separate articles. Wikivoyage nearby articles will present articles outside the location mentioned but in this case an automatic reduction of the zoom value is necessary. And if the zoom value is interactively reduced then the (new) nearby articles should be updated.

In my view, the disabling of Wikivoyage nearby would meet with a refusal in other Wikivoyage branches, too.

I don't really see that position in those 5 months old discussions...
What I see are a few VERY niche use cases, that could be filled by a rewrite of existing functionality, so that they no longer burden the core code with their presence. That would seems to be a much better direction to me rather than bothering viewers with several MB of locations they don't need every time they open a map....

fastest and most convenient solution to present about 30.000 markers. Its basically how everything worked BEFORE Kartographer.

Showing 30000 markers at once seems like something that should be used in only very few situations and is not a general purpose use case. Why not have a gadget that on that specific page, instead of loading the Kartographer map, loads https://wikivoyage.toolforge.org/w/poimap2.php ? That seems like it should be easy to do.

There is another problem: within a location like a town there are on Wikivoyage usually no other sites with separate articles. Wikivoyage nearby articles will present articles outside the location mentioned but in this case an automatic reduction of the zoom value is necessary. And if the zoom value is interactively reduced then the (new) nearby articles should be updated.

What I understand is that there are so few articles nearby, that in order to show up any results, you need to cast a wider net correct ? And then once you get those results, you need to zoom out in order to present those results ? So basically you need 'a minimum of results, even if not concentrated around the direct surrounding article"..... I think this is functionality that the coordinate search doesn't provide right now indeed.

Example: https://de.wikivoyage.org/wiki/Wissembourg
API query: https://de.wikivoyage.org/w/api.php?action=query&format=json&formatversion=2&prop=coordinates%7Cpageprops%7Cdescription&colimit=max&generator=search&gsrsearch=nearcoord%3A6200m%2C49.03%2C7.94&gsrnamespace=0&gsrlimit=300&ppprop=displaytitle

Returns just 2 results, because those are the only nearby articles in a 6200m range... Quite often you have to go to at least 20km distance to search point (radius, not diameter) to even get something useful back. And even if you manually zoom in or out, you have to press a button to load more search results. (Why is this ? Makes no sense to me, why not just debounce on zoom ?)

I don't really see that position in those 5 months old discussions...

Only now I/we realize the limits of the new Nearby feature. And the difference in the needs of Wikivoyage and Wikipedia projects.

What I see are a few VERY niche use cases, that could be filled by a rewrite of existing functionality, so that they no longer burden the core code with their presence. That would seems to be a much better direction to me rather than bothering viewers with several MB of locations they don't need every time they open a map....

It's true that there are only a few cases in which wereally need the existing functionality. In MediaWiki:Kartographer.js I can specify in which cases Wikivoyage nearby functionality should be used so that several MB of locations have not to be loaded every time. The functionality is/was already part of the WMF's Kartographer package so nobody has to program new gadgets, and it is the easiest way to use it. Unfortunately, https://wikivoyage.toolforge.org/w/poimap2.php is no longer supported by anybody.

I can understand that it is your wish to shorten the core code. But it means big efforts for the communities to re-establish this complex code in local wikis.

What I understand is that there are so few articles nearby, that in order to show up any results, you need to cast a wider net correct ?

You are correct. I am in contact with WMDE and I hope that a useful solution can be achieved.

In T332029#8733782, @RolandUnger wrote:

What I see are a few VERY niche use cases, that could be filled by a rewrite of existing functionality, so that they no longer burden the core code with their presence. That would seems to be a much better direction to me rather than bothering viewers with several MB of locations they don't need every time they open a map....

I'm wondering if this specific case, might not be easier handled by the wikidata query service btw.
Just https://w.wiki/6WBa (limited to 20000 for now) and then use the map representation for the results...