🇮🇹Italy @itamair

Ok ... I properly inspected all this issue and found the cause and the fix (that I pushed into dev) wasn't that complex.
Everything already deployed in new media_library_importer 2.1.5 release → , that should fix and be free from this.
Please test it out and eventually reopen this, if not solved ...

Thanks @Nate for this super detailed and clear report.
I will (would find some time to go) deeper in this and my analysis.
Did you eventually elaborated any clue on how to properly fix this?
Or just identified the code area that brings this incorrect behaviour ...
I mean. Do you already have a patch for this?

Thanks!

itamair → made their first commit to this issue’s fork.

thanks @valthebald for the clarification.
Well, actually my WIP was already provided with version 1.0.5, and now it looks that I should re-start over, with 1.1-beta.

Perhaps, in accordance with Drupal's semantic versioning model ( https://www.drupal.org/docs/distributions/degov/semantic-versioning-model → ) and given the discontinuation of BC, a new 2.0.x release would have been a better name for this branch... (?).

itamair → created an issue.

Thanks. Merged this ...

itamair → made their first commit to this issue’s fork.

itamair → created an issue.

just a further refinement, so to generate a GEOMETRYCOLLECTION only if more than one Geofield values, otherwise just use the first Geofield value (GEOMETRYCOLLECTION needs at least 2 sub features, otherwise Geojson is not valid, apparently).
The generated Geojson looks valid now on my side, on top of multivalue Geofields ...

Ready for QA and Review.

Please Test and QA ...
Would be (soo) nice to approve and create a new Views GeoJSON release with this, to provide a more extended and strong support for the Drupal Geofield module → .
Thanks!

itamair → created an issue.

bonnet clear what you mean (to me).
Anyway there is no presence of any "leafmap" string / term in the whole Drupal Leaflet module code base,
and that gives me the evidence that this issue of you is not related at all with this Leaflet module.

Hi @promes
what makes you thinking that this warning is coming and being caused by the Drupal Leaflet module?
From the waring you mention / pasted it looks totally unrelated to the Drupal Leaflet module ... isn't it?

Please also test new Leaflet 10.2.46 release → and check if that new release also fixes this issue.

New Leaflet 10.2.46 release → just deployed with #2 patch.
Closing this as FIXED ... please reopen if this issue still happening.

Anyway ... the error message that you describe looks similar to/ identical to the one reported also in this other issue) still related to Leaflet release 10.2.45 ...: https://www.drupal.org/project/leaflet/issues/3521371 🐛 Version 10.2.45 introduces a bug with Views tooltips. Active

Could you please QA and Review the patch attached in comment #2 in that Issue thread here (?):
https://www.drupal.org/project/leaflet/issues/3521371#comment-16087181 🐛 Version 10.2.45 introduces a bug with Views tooltips. Active
and let us know if that eventually fixes this issue on your side?

Thanks!

KML format is not directly supported in the Geofield ( https://www.drupal.org/project/geofield → ) and Leaflet ($this) modules, hence I assume you are referring to a user scenario where the Geocoder module ( https://www.drupal.org/project/geocoder → ) is being used to transform a KML file into a Geofield (WKT or GeoJson), throughout the KML Geocoder provided.

Well ... all looks good to me (and no sign or log of that error you report), also in the Geocoder module scenario and with Drupal Leaflet 10.2.45, as you can see in the attached screenshot where the attached simple.kml file is being geocoded into a Geofield field ...

Hi @mwynne ... don't really get what's happening on your side.
Make sure to set in "fields" the "Show" format of your Leaflet View style,
and select a for the "data source" option ...

All should be fine with that.

thanks @bigbaldy for reporting this,BUT I cannot reproduce what you report.

This Leaflet 10.2.45 based demo site / view:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geo-place/da...
is working correctly with tooltips (as you can clearly see), with not logging that error that you report.

You mention the Leaflet Formatter, but then your error reports the LeafletMap View style class,
and that is also a bit misleading ...
But also the Leaflet Formatters are working correctly, as you can see from these 2 example pages:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geo-place/da...
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/it/geo-place...

Anyway, may be your use case is having some specific Leaflet Tooltip token / replacement setup,
and some more solid and defensive code in parsing/casting that Render/Markup into a string is worth the case.

Could you please QA and Test the attached patch with the latest Leaflet 10.2.45 and confirm if that solves this issue of you, or still not?
And let us know here ...

thanks @john.oltman for reporting this ...
BUT I cannot reproduce any of the issue that you report.

Let's do it together, and with the new Drupal CMS (Drupal 11 based).

Please follow the steps on "How to install Drupal CMS using DDEV" as described on this page:
https://new.drupal.org/docs/drupal-cms/get-started/install-drupal-cms/in...

At the end of the ddev composer create drupal/cms command you will see that everything is being required without any issue and warning, and geocoder module is part of it ... because a dependency of the drupal/drupal_cms_events recipe.

But also let's try to specifically require the drupal/geocoder project, applying the following composer commands:

# remove the geofield stack module (and the geocoder module) along with the drupal/drupal_cms_events recipe
ddev composer remove drupal/drupal_cms_events recipe

#then let's specifically require the drupal/geocoder module:
ddev composer require drupal/geocoder

and all is being required correctly, to me ... with any of the warnings that you report.
Isn't it?

Could you kindly instruct me how to reproduce the warning that you experience and report, in the above (very general) scenario that I provided?
I need to have evidence that what you report is a general / established uses case ... and not a specific of you.

Otherwise I would Close this as "Works as Designed".

Thanks ...

Committed into 10.2.x dev branch.

thanks for providing all that @boulaffasae ... I am going through it and check asap

@boulaffasae thanks for reporting this and providing your MR !64 (and parallel patch)
but I am not going to approve and merge it for the following reasons:

1. I ask you to better elaborate about your logical findings in the breaking workflow in the correct enabling / availability of the required geocoder providers and the parallel (or subsequent) enabling of the geocoder submodules (geocoder_address, geocoder_field, and geocoder_geofield): could you properly explain what you mean with "submodule's interference with the Geocoder provider plugin configuration" and how and where it exactly happen?
Also could you explain what your MR !64 is supposed to accomplish and workaround those interferences?

2. I further (once again) tested the scenario that you describe (the way I got it ... ) with a fresh install of a Drupal 10 (and 11) instance, and a Geocoder 8.x-4.28 release, and I could find any issue in correctly enabling and using the required Geocoder Providers, also with subsequent (or previous) enabling of those geocoder submodules. You could see a detailed description of of my Test and QA in this comment of mine (in this parent issue): https://www.drupal.org/project/geocoder/issues/3153678#comment-16065922 🐛 How to add Gecoder 3.x providers Needs review

I am incline to Close this as "Works as Designed" asap, but I am still curious to read a further explanation of your problematic use case (those kind of interferences explained) and the solving logics of your proposed MR !64 ...

Because of some (really few) issues still being posted that relate to some difficulties in adding Gecoder 3.x | 4.x providers, and assuming that possibly related to the conflicting enabling of geocoder_field, geocoder_geofield and geocoder_address submodules (such this latest one: https://www.drupal.org/project/geocoder/issues/3518956 🐛 Geocoder Submodules Preventing Installed Providers from Displaying (e.g., Google Maps) Active )

I further performed a deep insight and QA & test that could try to replicate the reported problematic scenario,
and still I couldn't experience any issues in enabling those Gecoder Providers that I required, and still having them enabled after subsequently enabled those geocoder submodules.

In particular I accomplished the following tasks in the following sequence:

1. I installed a fresh Drupal 10 (or Drupal 11) instance (locally with DDEV);
2. Required and enabled the Geocoder module with the following commands:
ddev composer require drupal/geocoder
ddev drush en drupal/geocoder
all good ... the Geocoder 8.x-4.28 release is installed and enabled.
3. I required the google-maps-provider and arcgis-online-provider Geocoder providers with the following commands (--with-all-dependencies):
ddev composer require geocoder-php/google-maps-provider -W
ddev composer require geocoder-php/arcgis-online-provider -W
ddev drush cr (always better to clear the drupal cache)
all good ... I could then find the required geocoder providers in the Geocoder provider options list, at the admin/config/system/geocoder/geocoder-provider settings page (@see the attached screenshot)
4. I enabled the geocoder submodules geocoder_geofield (after requiring the geofield module) with the following commands:
ddev composer require drupal/geofield
ddev drush en geocoder_geofield
ddev drush cr (always better to clear the drupal cache)
and still all good ... I could still correctly find the required geocoder providers in the Geocoder provider options list, at the same geocoder-providers settings page (@see the same attached screenshot)
5. I also enabled the geocoder submodule geocoder_address (after requiring the address module) with the following commands:
ddev composer require drupal/address
ddev drush en geocoder_address
ddev drush cr (always better to clear the drupal cache)
and still all good ... I could still correctly find the required geocoder providers in the Geocoder provider options list, at the same geocoder-providers settings page (@see the same attached screenshot).

My further established conclusions on this are that all is working fine with the expected workflow to require and add Geocoder Providers with actual Geocoder 8.x-4.28 release

this looks solved to me with latest Geofield Map release (11.0.x)

may be something changed / improved since you opened this, but now it looks what you report here is not really true.
The default Camera Control appears in the Google Map generated by the Geofield Map module, as you can see from the attached screenshot and the Demo site itself: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/

Hey ok ... let's hopefully solve all this, once and for all.
I made a definitive test (using the new Drupal CMS) that clearly proves how the geocoder-php/arcgis-online-provider geocoder provider is correctly required and works correctly with the current version of the Geocoder module (8.x-4.x).

Please accomplishe the following steps, to achieve the same evidence:

1. Install the new Drupal CMS (https://new.drupal.org/docs/drupal-cms/get-started/install-drupal-cms) choosing the Events recipe/profile: the Events recipe requires Geofield, Leaflet and Geocoder modules, and also by default the geocoder-php/nominatim-provider provider ...

2. once accomplished point 1, then require the geocoder-php/arcgis-online-provider geocoder provider with the following ddev / composer command:

ddev composer require geocoder-php/arcgis-online-provider

and clear the drupal cache (drush cr)

3. go to the Geocoder provider settings (/admin/config/system/geocoder/geocoder-provider) to have evidence that the ArcGisOnline is now correctly available among the options of the Geocoder Providers options (see the attached screenshot).

and that's it ...

Please, for further informations and issues on to how correctly add Gecoder 3.x | 4.x providers please refer to this longstanding and still open issue: Gecoder https://www.drupal.org/project/geocoder/issues/3153678 🐛 How to add Gecoder 3.x providers Needs review

Well actually indeed I can recall that I already Closed (as Won't Fix) this parent Issue / Feature Request with the same reasons.
Such also this one: https://www.drupal.org/project/geofield/issues/3042880#comment-13039900 →

Thus I am closing also this Feature Request as won't fix.
I am still not persuaded to implement all this in the Geofield code base ...
BUT you arel free to implement your specific alterations in your specific use case and Drupal project instance.

There are many issues (drawbacks) that I see in this feature request and its actual implementation.

Regarding the feature request itself (to not expose the distance value in the Exposed Filter) I have the following blocking issues:
- I don't get which is the normal and recurring use case and need for doing this. It should always be evident to the uses the distance the proximity search is being performed upon. So I really don't get the reason to hide it;
- rather than completely hide the distance value, it should at least kept as a read only value in the Exposed Filter, to keep it still evident all the parameters of the Proximity Filter (both origin and distance).

Regarding the actual MR !40 state, that I quickly QA and Reviewed I can clearly see the following issues:
- the newly added "Expose distance field" checkbox element is totally disconnected from the "Distance" textfield and this is very bad from the UI/UX perspective. Why this is not kept close to the Distance element?
- once the "Expose distance field" is unchecked and the Proximity filter settings popup is saved than it becomes impossible to check and change the Distance element, both in case the filter is set as exposed and when not. This is super bad and makes everything totally unusable and not properly configurable ...

How did you test and QA this MR !40 state implementation?

BTW ... as general feeling I am really not incline to accept this Feature Request and implement it in the Geofield Proximity filter code base,
because this use case need looks very singular to me, and for accomplishing this I would still suggest you to override the @GeofieldProximitySource you are using (with a custom of you) and later its buildOptionsForm method, or even more simply use an hook_form_alter on the exposed filter form itself (and hide or make it readonly or disable the exposed Distance field),
as I already suggested in this comment: https://www.drupal.org/project/geofield/issues/3273483#comment-14475860 →

I would personally really close this as "won't fix".

Let’s try to keep staying respectful and polite here,
Where we are providing feedback and support mostly for free.
…
This issue looked pretty old to me and with no contribution for a long while,
And I guessed it was already solved.

Especially as consequence of numerous lates posts that clearly explain how to interact with Drupal Leaflet map, once it is generated.

For instance this one: https://www.drupal.org/project/leaflet/issues/3047091 📌 Leaflet Map & Markers external interaction, on events - LIVE DEMO Needs review
that points to the Live Demo,
and explains how to interact with the Leaflet Map and its features.

Basically in your case you will need to re center the Leaflet Map against the latest / newest Marker on the map.

How to pick the newest?
Well, taking it as the last if properly ordered by the Leaflet View sorting,
Or adding each date to each feature with the Leaflet Feature hook, ecc.
Kind of that …

Hope this helps.
Happy extending your Leaflet Map!

ok ... also interaction on the Geofield Map View page was improved. Now it works in an acceptable way.

Hi @òrahulkhandelwal1990 thanks for your head-up.
Indeed the Live Demo link was still pointing to a previous address.
I corrected it in this post description into this update and correct one:

https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-gm...

Also the weblink to the geofield_map_interaction.js file mentioned in the Left sidebar block as initial guidance & inspiration of this interactivity was corrected.

Additional Note: On this Geofield Map View page the interaction is not working so great (the Google Map Infowindow sometimes doesn't open, etc.) as it is in the corresponding Leaflet View interaction example: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
Not sure why, at the moment ... but I will find sometime to better inspect and improve it.

Ok ...
so, do you really want to keep this open, with "needs work"?
I don't think this can cope in code every possible user use cases (and custom Leaflet Map Info definitions),
and that can end up into the Leaflet module code base.

Could we rather close as "Closed (works as designed)"?

Ok ... I went much better through all this,
and required & enabled the Content Security Policy module on my local instances of the following 2 (Leaflet powered) websites:

https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma... (Official Leaflet Module Live Demo)
https://www.taranto-viva.com/it

Yes indeed, all the Leaflet maps break 8and not only the Leaflet widgets maps), with a long list of errors/warnings in the inspector console ... etc.

But also the MR !31 Draft doesn't help on this ... and all still looks broken.
It looks that is trying to cope some very specific use case and Leaflet context, that means if the Open Street Map Tile (default in the module) is used ... and for the widgets.

But it looks that also Leaflet Formatters and Leaflet View Styles are breaking ... isn't it?
And e should consider that in most cases users will implement different Leaflet Map background tiles ... (from Open Street).

May be I didn't get the proper issue case (as I am not fully understanding all the CPS options and functionalities, etc)
BUT I don't think/feel the correct use of the CSP should be restored with whitelisting with additional code in the Leaflet module,
but rather with specific whitelisting in the CSP module settings, or eventually in custom modules by users implementing it ...

What could be a general fix in this Leaflet module instead, eventually? (that could solidly cope all the possible Leaflet Map Tiles implementations?)

I cannot replicate this issue ...
To me, the actual Leaflet module release (10.2.43) can correctly render different Leaflet Popups and Tooltips
according to the translated version of the content and the language selected for the specific page.

For instance you can see this Italian / English implementation:
https://www.taranto-viva.com/en
https://www.taranto-viva.com/it

Please, close the first welcome popup, just zoom in and check both the Popup and Tooltips on some of those icons,
such the "Cathedral of San Cataldo", for instance ...

Suggestion: make sure you set in the View settings:
Language
Rendering Language: Content language selected for page

Screenshots attached ...

10.000 thousands features is pretty a lot ... and may be too much indeed.
And for sure you should enable the Leaflet Markecluster (sub)module (and its settings), at least trying that.

Views GeoJson module could be a nice option, but for sure won't reduce the number of features that you try to load ...

With that you should try to implement a Decoupled Solution that simply fetches that GeoJson data response.

Leaflet View map is only going to fetch data from a Leaflet Map View style,
or may be you simply can try to replicate this Leaflet View Geojson Demo example here:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geojson-map-...
(@see the linked "leaflet_map_geojson.js" file in the right sidebar ... )

but for sure that approach won't easy the load and effort of such a big amount of features.

hi @joaomachado ...
thanks for posting this.

Your description is a bit confusional.
You mention different content types labelled as Origins, or Destinations, then you also mention the Proximity Module, that is not clear what it is ... and also you ask if you could mix the Leaflet module functionalities with the Google Routes API,

Well. it's hard to be exhaustive here, without spending a lot of time (that personally I don't have now ...).
But I would point you into some helpful directions, possibly.

If you implement a Leaflet View Map then you should eventually be able to add to it the:
Leaflet Routing Machine (https://github.com/perliedman/leaflet-routing-machine) and build your own interactive solution on top of it ...
How?
Well, you should be able to master Leaflet Js library and its plugins and know how to extend the Drupal Leaflet Map View.
Probably this Drupal Leaflet issue should provide you with proper hints: https://www.drupal.org/project/leaflet/issues/3047091 📌 Leaflet Map & Markers external interaction, on events - LIVE DEMO Needs review

Google Routes API? may be also ... but in that case you will send the user out of the Drupal website for processing the navigation operations.

May be also the Geofield Directions module could be inspirational to you: https://www.drupal.org/project/geofield_directions →
Also see this dedicated brief video: https://www.youtube.com/watch?v=7HxuVQ8WlNA
As far as I understood it simply implements a Geofield Formatter that Links out to a Google Map that presets that Target Direction from ... well, I guess where you are, or whatever you choose as Google Map starting point.

But may be you could grab its code, and eventually generate a Computed Field that automatically generates a Google Map link with preset both origin and destination taken from a pair of Origin and Destination geofield entities ...

Kind of all that / those ...

vrancje → credited itamair → .

Thanks @bachbach for reporting this ...
could Test and QA the attached patch?
It should restore backward compatibility on this.

Well ... the server type shouldn't make any difference in my opinion,
BUT (anyway) of course we are also testing all this on Linux based servers.

More specifically it works correctly locally on DDEV docker web image: https://hub.docker.com/r/ddev/ddev-webserver
and it also works correctly here: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/
that is (of course) based on linux servers ...

BUT, rather then going around vague assumptions, why you don't provide more info on your error logs ... ?
what is not working with your "arcgisonline" provider instance?
Are you able to XDebug what is happening on your code workflow?
Are you checking it locally .. or directly on the production server? (not nice practice, in such latter case).

I am pretty confident that it could highly depend on your specific configuration setup. May be something was messed up in your Arcgisonline configuration setup ...
Would highly recommend you to remove all of it and re require it via composer
composer require geocoder-php/arcgis-online-provider
and re-enable it from scratch with your Drupal backend configuration.

The original lower case
id = "arcgisonline"
never changed over the last bunch of years, and no-one reported this same issue of your, for a Geocoder provider that is basically free for use, and definitely much used also with this Drupal Geocoder module ...
No-one else have reported this same issue ...

Great catch @ivnish ... thanks.
QAed successfully.
Merging and deploying a new 2.1.3 release with this ...

Adding reference to the parent issue, that I had do autonomously look for ... and find,
and that wasn't approved and merged, because not needed.

I better inspected this, and nothing looks wrong to me in the actual 8.x-4.x code,
and everything (still) works correctly with the "ArcGisOnline" (id = "arcgisonline") Geocoder provider.

Changing this into "Support Request" (because no proof/evidence of Bug) and closing as everything "works as designed" ...

Please provide better info context next time, and make better internal debug, because everybody time is precious.
and please don't reopen this without clear evidence / proof of your assumptions..

Thanks @dianacastillo for reporting this
But it looks to me you are rushing and not providing proper context.

You mention that this change was already made for another version, but you don’t provide where this change was made, and for which version.
Can you provide reference to the parent (or related) issue you are speaking about, or just the link to “that” commit?
So this audience could better understand what kind of regression you are referring to, and how to reproduce.

Also, once you create a fork you should also generate a MR (merge request) if you ask for final review and eventual merge of it.

I will be able to better inspect this tomorrow (if you please provide better info and context) and merge it, eventually, if worth to be approved.

Thanks ... committed into dev, will be part of next Geocoder release.

Patch #4 committed into dev branch, will be part of next Geocoder release.

Ok ... got all this.
New leaflet 10.2.43 release → (just deployed) is fixing this,
and is also keeping fixed the related https://www.drupal.org/project/leaflet/issues/3377484 🐛 Uncaught Error: Invalid LatLng object: (NaN, NaN) Active one.

Closing this as fixed.

Hey @wsantell ... thanks for reporting this, and sorry for this regression.

Please, let me properly understand the specific context.

You say ...

Steps to reproduce
View a geofield which uses the Leaflet Map format, with "Field" Map Icon using custom icon size and anchor settings
Observe that the marker is 12px x 12px and offset -6px left and up.

BUT, is this happening only in case of DivIcons ... right?
Can you confirm that we should test and reproduce this specifically with DIVIcon?

Because that commit only changed the Drupal.Leaflet.prototype.create_divicon function ...

thus ... could you QA and test the last attached patch and eventually mark this as RTBC eventually ... to approve (green flag) its commit into dev?

ah ok ... better got it.
It is CommerceGuys\Addressing DefaultFormatter adding that "\n"
but it is the Geocoder AddressService here:
https://git.drupalcode.org/project/geocoder/-/blob/8.x-4.x/modules/geoco...
that is converting it into a space ... rather than something more clear separator for the Geocoder provider, such comma ...
right?

Thus what about replacing both the "\n" and the "
" eventually into a comma instead (",")??
You propose ...

Ok. I attache here an updated patch that adds these new replacements (in place of a space).
Could you carefully and extensively test that and eventually confirm this would improve the Geocoder AddressService on a general basis, in your feelings?
I think/assume that a comma (,) separator between different Address parts should be more clear with every Geocoder provider, isn't it?

Let me know your outcomes with this new patch, please.

thanks for reporting all this @tklawsuc
BUT outcomes of my QA and tests reproducing your use cases say that all this happen on singular cases (Issue 1)
and strangely depending on the Geocoder Provider that you use.
Issue 2 happens only with Nominatim ... and the address line 2 doesn't compromises correct Geocoding with others, such as Photon or Google Maps.

The best approach that I would propose is contained into the attached patch,
that I feel could also benefit the related issue: https://www.drupal.org/project/geocoder/issues/3335292 🐛 Incorrect geocoding when suite number included in address Postponed: needs info

A new "geocoder_address_values_alter" hook (in the "geocoder_address" submodule) that might allow any custom module to change/alter the Address Values array (at your specific use case) before it is stringified by the AddressService: addressArrayToGeoString.

That can also do something like the following, to remove the "address_line2" value:

/**
 * Implements hook_geocoder_address_values_alter().
 */
function [custom_module]_geocoder_address_values_alter(array &$values) {
  $values["address_line2"] = '';
}

Please Qa and test this attached patch.
I am pretty convinced to commit and add that into a new incoming Drupal geocoder 8.x-4.28 release ...

Sure we should! Thanks @acbramley
Committing into 8.x-4.x dev branch ...

itamair → made their first commit to this issue’s fork.

thanks @ovquiaf ... Qa and Tested what you say and it makes sense to me.
Committed into dev (with some better ternary operator implementation) is going to be part of the news (incoming) Geocoder release.

Hey @bavramor what are you referring and looking into?
What you state here looks totally wrong ...

Did you ever inspect the Drupal Leaflet module libraries definitions?
And in particular the leaflet/leaflet library definition one here (?):
https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/leaflet.librari...

leaflet:
  remote: http://leafletjs.com/
  version: 1.9.4
  license:
    name: Leaflet-License
    url: https://github.com/Leaflet/Leaflet/blob/v1.9.4/LICENSE
    gpl-compatible: true
  js:
    js/leaflet/dist/leaflet.js: {}
  css:
    component:
      js/leaflet/dist/leaflet.css: {}

All is indeed (already) being embedded in the module itself and loaded from it.

And if not (if it wasn't the case) you should know that you could always implement your own hook_library_info_alter() and alter it in your own way ...
(rather than defining and adding a new my_theme.libraries.yml, kind of un-appropriate).

Further more you could have also better inspected already existing Drupal leaflet module issues and easily found that GDPR issues / matters have already been discussed in this existing fixed issue:
https://www.drupal.org/project/leaflet/issues/3086698 ✨ Use Leaflet GDPR conform Active

Please, make your deep(er) investigation and inspection of all these things before opening new issues, that look so far from reflecting the actual version of the Drupal Leaflet module (because everybody time is precious ... ).

Confident all this helps and points you in the proper direction ... and happy Drupal use & contribution too
(sorry to mention, but your longstanding Drupal profile looks still soo sadly empty on that side).

thanks @aren33k for reporting this ...
well, indeed something could have happened moving from 10.3.x into 10.4.x Drupal Core that I am not clearly aware of ...
but let's try to better describe and fix this issue of you.

First of all, if you the Leaflet Map that it means that the following events:

'leafletMapInit': https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/js/leaflet.drup...
'leaflet.map': https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/js/leaflet.drup...

are both being fired (for sure).
They act exactly as the same, and could be use without any difference.
The 'leafletMapInit' was introduced to provide a better (self explaining) naming, and the 'leaflet.map' was still kept not to break backward compatibility.

What is rather and (very) probably happening is that something changed in the ways different js libraries are being loaded, in terms of each other dependency.

For having this code of you:

$(document).bind('leaflet.map', function (event, settings, lMap) {
        console.log('fired')
      });

correctly intercept (react upon) on of those 2 triggered events you js library (that embeds that code) should be loaded BEFORE the leaflet.leaflet-drupal library itself, that has now the following default definition:

leaflet-drupal:
  js:
    js/leaflet.drupal.js: {}
  dependencies:
    - core/jquery
    - core/once
    - core/drupal
    - leaflet/leaflet

has you can see from here: https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/leaflet.librari...

So, it means that [your_custom_module.your_custom_library] should become an additional dependency on that.
How could this be done?

Well ... you need to implement the following hook_library_info_alter() in [your_custom_module.module] file,
such the following:

/**
 * Implements hook_library_info_alter().
 */
function  your_custom_module_library_info_alter(&$libraries, $extension) {
  if ($extension == "leaflet") {
   $libraries['leaflet-drupal']['dependencies'][] = ' your_custom_module/.your_custom_library';
  }
}

In that way you will force and inject your library as dependency for the leaflet-drupal library itself (as defined by the Leaflet module/extension),
and correctly make your code ready for listening and catch the 'leaflet.map' (or 'leafletMapInit) event ...

All clear?

Otherwise, second quick (no code) option would be to simply enable " Lazy load map" for your Leaflet View Style or Leaflet Formatter option ... (@see the attached screenshot).

Hope (and very confident) this will help and fix this issue of you ... that s not indeed a clear Bug of the Leaflet module.
Let's change all this into a Support Request.

And let us know if indeed all this fixes this, and move it accordingly to Fixed or Needs Work/Active, etc.

This was finally resolved in its parent Infrastructure issue.

Thanks! I confirm that it can be correctly required via composer ...

itamair → created an issue.

could you also try yourself on a local Drupal CMS instance of you ... or any other Drupal 9 or 10 instance?

thanks for the tip ...
but no way, still.

~/Sites/Drupal_CMS_package/drupal-cms git:[master]
composer show drupal/drupal_cms_geo_images -a --no-cache
name     : drupal/drupal_cms_geo_images
descrip. : 
keywords : 
versions : 1.1.0, 1.0.6, 1.0.5, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0
type     : drupal-module
license  : GNU General Public License v2.0 or later (GPL-2.0-or-later) (OSI approved) https://spdx.org/licenses/GPL-2.0-or-later.html#licenseText
homepage : https://www.drupal.org/project/drupal_cms_geo_images
source   : [git] https://git.drupalcode.org/project/drupal_cms_geo_images.git 1.1.0
dist     : [zip] https://ftp.drupal.org/files/projects/drupal_cms_geo_images-1.1.0.zip 1.1.0
names    : drupal/drupal_cms_geo_images

support
source : https://git.drupalcode.org/project/drupal_cms_geo_images

requires
drupal/core ~8.0

Sorry @drumm but I feel to reopen this,
as the following composer require commands:

ddev composer require drupal/drupal_cms_geo_images
ddev composer require drupal/drupal_cms_geo_images:^1.0

are always and still returning the following (same require drupal/core ~8.0) error:

  Problem 1
    - Root composer.json requires drupal/drupal_cms_geo_images * -> satisfiable by drupal/drupal_cms_geo_images[1.0.0, ..., 1.1.0].
    - drupal/drupal_cms_geo_images[1.0.0, ..., 1.1.0] require drupal/core ~8.0 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev] but the package is fixed to 11.1.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require drupal/drupal_cms_geo_images:*" to figure out if any version is installable, or "composer require drupal/drupal_cms_geo_images:^2.1" if you know which you need.

and also the following

ddev composer show drupal/drupal_cms_geo_images -a

still returns

requires
drupal/core ~8.0

Why is this still not working as expected, and simply

requires
"drupal/core": ">=10.4"

Its code base is indeed the same of this parallel packagist, deployed on the branch 2.x with composer.json name: itamair/drupal_cms_geo_images
and on which the following composer require works and applies fine on Drupal CMS (11.2):

ddev composer require itamair/drupal_cms_geo_images

Could you also test and confirm that I am not doing anything wrong here and what could be wrong still and instead?

thanks for reporting this @morganlyndel ... I quickly inspected this, but indeed this is not on the Drupal side.
It is all on the Google Maps way and how they are providing those map controls structure ...

Closing this as "works as designed".

Feel free to re-open if you better inspect and rather find that it is the opposite case (all due to Drupal)

thanks a lot @drumm for this quick fix.

Well, of course I looked into the
Drupal.org Recipes page: https://www.drupal.org/docs/extending-drupal/drupal-recipes →
(and nothing from there, and also both in the Distributions and Recipes initiative and the Drupal Recipe Cookbook referenced pages, etc.)

I also think something should / might be clearly mentioned in the following pages:

• How to create a new project → , where the "General Project" is described ...
• the https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → , itself ...

itamair → created an issue.

Ok good. yes now you Leaflet Popups look perfect and well aligned!

And let's keep this as my further comment to attach the Credits to.
Well yes, I committed the new version because I clearly saw that fix...
and I (and my anarchistic workflow :-) ) was just expecting a RTBC here, before my final Fix.

@ressa a mean this ... (@see attachment)

Nice ... and thanks @ressa for marking this as Fixed,
but two final questions from me:

1. in the map you mentioned it looks the Leaflet Popup is appearing in place, but not perfectly aligned (horizontally) with the DIV Icon ... May be that is the wanted outcome or a minor issue of the Div Icon itself?
2. did you properly assign / checked Credits to all the contributors here, before setting this as Fixed?

thanks @ressa ... your report better brought me to the proper direction and fix (hopefully).

Could you (everybody) QA and Review the 10.2.39 release → that I just released (very confidentially), with this last commit: https://git.drupalcode.org/project/leaflet/-/commit/a8a203b21d3932238760...
for fixing this bug?

hey ... @ducdebreme thanks for reporting this.
BUT why do you assume this is a bug?
Do you have clear evidence of that?
Do you provide it ... ?
Or do you simply feel things don't work as you expect?
Well, that is not a clear bug ... but probably something that you missed or misunderstand.
Please don't provide Issues marked as BUG, when you don't have (and provide) clear evidence of that.
Rather create Support requests, that could be eventually turned into Bugs, when confirmed.

Indeed in this case you are simply mislead.
If the geocoder_address submodule is enabled, Address field can be indeed:
be Geocoded from an existing field
or Reverse Geocode from a Geofield type existing field.
(as mentioned in your screenshot itself).

Ah pretty weird @orkut murat yılmaz eh!
It would be great (much better) if you could also add some screenshot that make more sense clear your use case
(i.e. that show your maker at zoom 5 and how then it looks, and where, at zoom:12, etc).

Just going kind of blind,
and according to this solution (https://stackoverflow.com/questions/17875438/leafletjs-markers-move-on-zoom)
you might try to set dimensions of the Leaflet Icon
(@see the attached screenshot)

This latest commit: https://git.drupalcode.org/project/leaflet/-/commit/e8dceda8a070ed989c79... implements this new Feature.

itamair → created an issue.

Ah damn! Right you are ... I simply forgot about that "get push access" button.
So I did and pushed my further commit.
As said, in this state MR!458 fixes this issue and use case of mine ...