Leaflet: L.Icon.Default apporte une mauvaise URL d'image

• Existe-t-il une page Web publique sur votre serveur que nous pouvons visiter, afin que nous puissions reproduire le problème nous-mêmes ?
• Quel système d'exploitation et navigateur Web utilisez-vous ?

brochure.min.js:5 GET https://uismedia.geo-info-manager.com/apis/leaflet_1/images/ 403 (Interdit)

Cela peut provenir du même problème discuté dans https://github.com/Leaflet/Leaflet/issues/4849

En effet. C'est pourquoi je suis curieux de connaître les circonstances dans lesquelles cela peut être reproduit, afin que nous puissions faire des tests unitaires contre celles-ci.

J'ai eu le même problème en passant de RC3 à 1.0.1 - dans mon code, j'avais la ligne L.Icon.Default.imagePath = 'images'; - je ne me souviens pas très bien pourquoi, mais le commenter a résolu le problème - cela vaut peut-être la peine de vérifier que vous n'avez pas de similaire

a soudainement eu le même problème dans deux projets complètement différents, utilisant tous deux le webpack et le dépliant.
Si j'ajoute des marqueurs à la carte, les images ne sont pas trouvées. Le navigateur renvoie cette erreur :

ok j'ai quelque chose.

Un marqueur ressemble donc à ceci actuellement car les images (icône et ombre) ne sont pas trouvées.

cette fonction en dépliant :

_getIconUrl: function (name) {
    if (!L.Icon.Default.imagePath) {    // Deprecated, backwards-compatibility only
        L.Icon.Default.imagePath = this._detectIconPath();
    }

    // <strong i="10">@option</strong> imagePath: String
    // `L.Icon.Default` will try to auto-detect the absolute location of the
    // blue icon images. If you are placing these images in a non-standard
    // way, set this option to point to the right absolute path.
    return (this.options.imagePath || L.Icon.Default.imagePath) + L.Icon.prototype._getIconUrl.call(this, name);
},

fait que les URL data:image ont la chaîne suivante à la fin de l'url :
")marker-icon-2x.png .

Le nom du fichier peut être supprimé si vous supprimez + L.Icon.prototype._getIconUrl.call(this, name) . La partie ") provient probablement de la magie des regex _detectIconPath . Je ne peux pas résoudre ce problème, alors j'ai juste essayé de couper les deux derniers caractères, ce qui donne cette fonction :

_getIconUrl: function (name) {
    if (!L.Icon.Default.imagePath) {    // Deprecated, backwards-compatibility only
        L.Icon.Default.imagePath = this._detectIconPath();
    }

    // <strong i="21">@option</strong> imagePath: String
    // `L.Icon.Default` will try to auto-detect the absolute location of the
    // blue icon images. If you are placing these images in a non-standard
    // way, set this option to point to the right absolute path.
  var url = (this.options.imagePath || L.Icon.Default.imagePath);

  return url.slice(0, - 2);
},

et c'est parti, l'icône apparaît. Un dernier problème est que l'image de l'ombre est également une icône de marqueur - le chemin src est déjà faux, je ne sais pas pourquoi (encore). Ainsi, un marqueur ressemble maintenant à ceci :

@IvanSanchez est-ce que cela vous aide à

@codeofsumit serait bien de parcourir _detectIconPath et de voir ce qui se passe là-bas, en particulier quelle valeur la variable path a-t-elle avant de passer par l'expression régulière.

@IvanSanchez @perliedman Je pense avoir trouvé le bug.

C'est _detectIconPath

_detectIconPath: function () {
    var el = L.DomUtil.create('div',  'leaflet-default-icon-path', document.body);
    var path = L.DomUtil.getStyle(el, 'background-image') ||
               L.DomUtil.getStyle(el, 'backgroundImage');   // IE8
    document.body.removeChild(el);

    return path.indexOf('url') === 0 ?
        path.replace(/^url\([\"\']?/, '').replace(/marker-icon\.png[\"\']?\)$/, '') : '';
}

la variable path ressemble à ceci :
url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAApCAYAAADAk4LOAAAFgUlEQ…n3EUrUZ10EYNw7BWm9x1GiPssi3GgiGRDKWRYZfXlON+dfNbM+GgIwYdwAAAAASUVORK5CYII=") .

Qui est correct.

Maintenant, l'expression régulière veut en extraire l'url data.image, et elle renvoie ceci :

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAApCAYAAADAk4LOAAAFgUlEQ…n3EUrUZ10EYNw7BWm9x1GiPssi3GgiGRDKWRYZfXlON+dfNbM+GgIwYdwAAAAASUVORK5CYII=")

Notez le dernier ") qui n'est pas supprimé de la variable path . L'expression régulière /^url\([\"\']?/ ne cible que url(" au début du chemin, pas le ") à la fin.
L'utilisation de cette regex fonctionne :

return path.indexOf('url') === 0 ?
    path.replace(/^url\([\"\']?/, '').replace(/\"\)$/, '').replace(/marker-icon\.png[\"\']?\)$/, '') : '';

Cela résout le problème d'image, ainsi que

var url = (this.options.imagePath || L.Icon.Default.imagePath);

à l'intérieur de _getIconUrl . Mais cela ne répare pas l'ombre - je ne sais toujours pas ce qui se passe avec l'ombre.

ayant le même problème,
la valeur du chemin dans _detectIconPath est quelque chose comme "url("data:image/png;base64,i...5CYII=")"
et il semble que _getIconUrl et _detectIconPath n'aient pas été conçus pour gérer les URL de données

le problème d'ombre semble être dû au fait que dans _getIconUrl la valeur de L.Icon.Default.imagePath est déjà définie avec l'URL des données du marqueur, donc l'image du marqueur est utilisée et étirée

cela pourrait-il être lié à ce commit codant en dur l'image du marqueur ?
https://github.com/Leaflet/Leaflet/commit/837d19093307eb5eeb1fca6536962a1ab1573dd5

@Radu-Filip J'ai pu le réparer avec ces modifications à votre PR - je ne sais pas quels autres effets cela pourrait avoir cependant :

Le problème est - comme vous l'avez dit - que l'URL par défaut est l'image du marqueur, pour toutes les icônes essentiellement.
Alors tout d'abord, j'ai ajouté l'URL par défaut pour l'ombre au CSS :

/* Default icon URLs */
.leaflet-default-icon-path {
    background-image: url(images/marker-icon.png);
}

.leaflet-default-shadow-path {
    background-image: url(images/marker-shadow.png);
}

Ensuite, j'ai passé le nom de _getIconUrl à _detectIconPath et je l'ai utilisé pour ajouter la classe à l'élément à partir duquel le chemin est extrait :

_getIconUrl: function (name) {

  L.Icon.Default.imagePath = this._detectIconPath(name);

    // <strong i="15">@option</strong> imagePath: String
    // `L.Icon.Default` will try to auto-detect the absolute location of the
    // blue icon images. If you are placing these images in a non-standard
    // way, set this option to point to the right absolute path.
  var path = this.options.imagePath || L.Icon.Default.imagePath;
  return path.indexOf("data:") === 0 ? path : path + L.Icon.prototype._getIconUrl.call(this, name);
},

_detectIconPath: function (name) {
    var el = L.DomUtil.create('div',  'leaflet-default-' + name + '-path', document.body);
    var path = L.DomUtil.getStyle(el, 'background-image') ||
               L.DomUtil.getStyle(el, 'backgroundImage');   // IE8

    document.body.removeChild(el);

    return path.indexOf('url') === 0 ? path.replace(/^url\([\"\']?/, '').replace(/(marker-icon\.png)?[\"\']?\)$/, '') : '';
}

J'ai également dû supprimer le if/else autour de detectIconPath , car il n'était pas appelé pour l'icône de l'ombre. Maintenant, tout fonctionne pour l'icône de marqueur par défaut - pas sûr pour les icônes personnalisées.

@codeofsumit ouais, j'ai fait quelque chose de similaire ici https://github.com/Radu-Filip/Leaflet/tree/temp
et je vais l'utiliser pour l'instant comme hack. Espérons qu'il y aura une solution plus à l'épreuve du temps pour ceux qui utilisent webpack et al.

@Radu-Filip, cela vous dérange-t-il de mettre à jour vos relations publiques avec cette solution ? Il peut être fusionné.

@codeofsumit terminé, voyons si cela passe

Salut,

Peut-être que j'ai raté quelque chose, mais il me semble que ce problème de construction de Webpack pourrait être simplement résolu avec un plugin Leaflet, qui remplacerait le comportement L.Icon.Default .

Démo : http://playground-leaflet.rhcloud.com/nexo/1/edit?html ,css,output

Avec cette approche, vous vous débarrassez de toute RegExp délicate et les images de marqueurs par défaut sont intégrées (par codage en dur), ce qui est de toute façon l'un des résultats attendus de Webpack pour les petites images.

Un inconvénient possible est que chaque marqueur a sa propre icône base64, je ne sais pas si les navigateurs peuvent la mettre en cache… (même inconvénient pour le PR #5041)
On pourrait imaginer un raffinement en le définissant comme image de fond au lieu de le placer dans l'attribut src , comme cela a été fait pour l'icône Layers Control par exemple.
Il peut y avoir un piège caché avec cette idée (modifier: ça ressemble à celui-là ), sinon je suis sûr que cela aurait été mis en œuvre il y a longtemps, car cela aurait évité la détection du chemin de l'image en premier lieu.

Démo : http://playground-leaflet.rhcloud.com/mey/1/edit?html ,css,output (ne prenant pas soin de la rétine)

Le plus grand avantage de l'approche du plugin est qu'il conserve ce comportement spécifique pour les projets Webpack uniquement.

J'espère que cela t'aides.

BTW, il me semble qu'il y a quelque chose qui ne va pas intrinsèquement ici.

Leaflet effectue une détection de chemin « complexe » vers les images, qui doivent se trouver à un endroit prédéfini par rapport au fichier CSS.

Mais le processus de construction de webpack regroupe ce CSS et peut (ou non) déplacer les images également (et les renommer !), en fonction de ce que le développeur demande à webpack (comme exiger des images).
Par conséquent, la détection de Leaflet échoue sûrement lorsque webpack est utilisé.

PR #5041 est comme une astuce pour accepter le cas où le webpack insère des images dans le CSS, au prix de la duplication de l'image Base64 dans chaque marqueur. Sans même parler du coût pour les utilisateurs non-webpack.

Le PR # 4979 était uniquement destiné à empêcher le message d'erreur de construction du pack Web (en raison d'un fichier manquant), il ne semble pas gérer du tout la résolution réelle du chemin de l'image.
Je suppose que les développeurs spécifient alors manuellement le L.Icon.Default.imagePath ?
@jasongrout et @Eschon , peut-être pourriez-vous partager comment vous l'avez géré ?

Je ne le gère pas vraiment. Je n'utilise tout simplement pas l'icône par défaut, ce bug n'était donc pas un problème pour moi jusqu'à présent.

Salut, juste une note pour dire que je peux reproduire cette erreur de chemin en utilisant la version 1.0.1 de cette bibliothèque.
Je l'utilise avec la brochure du module Drupal (7.x-1.x-dev), et ici il y a un problème signalé au module : https://www.drupal.org/node/2814039 au cas où il utile.

Autant que je sache, le "problème" est sur la fonction _getIconUrl ? comme après L.Icon.Default.imagePath il y a une barre oblique manquante, donc le chemin de l'image par exemple dans Drupal est généré comme ceci " /sites/all/libraries/leaflet/imagesmarker-icon.png ". Entre le chemin des images et le nom du fichier image du marqueur (marker-icon.png) doit se trouver une barre oblique /.

Salut @anairamzap-mobomo,

On dirait que ce que vous signalez est un problème différent.

Malheureusement, comme il semble impliquer un portage vers un framework (Drupal), vous devez d'abord vous assurer que le bogue n'est pas lié au fonctionnement de ce portage.

La brochure 1.0.x avec vanilla JS inclut correctement la barre oblique finale : http://playground-leaflet.rhcloud.com/fosa/1/edit?html , sortie

Voir par exemple http://cgit.drupalcode.org/leaflet/tree/leaflet.module#n51 , où L.Icon.Default.imagePath est surchargé par le module Drupal.

On dirait que ce module ne gère pas le changement entre Leaflet 0.7.x et 1.0.x, où la barre oblique doit maintenant être incluse dans L.Icon.Default.imagePath .

Comme Leaflet 1.0.0 est une version majeure, je suppose qu'il n'y a aucun engagement de compatibilité descendante.

hey @ghybs je vois... Je vais contacter les mainteneurs du module Drupal pour leur faire savoir cela. Comme vous l'avez dit, il semble qu'ils doivent modifier le module pour qu'il s'adapte bien à la version 1.0.x de la bibliothèque, ou au moins ajouter quelques lignes à la documentation mettant en garde à ce sujet.

Merci pour vos commentaires!

J'ai exactement le même problème que celui signalé à l'origine - dans un projet aurulia squelette/esnext+webpack.

Jusqu'à ce que cela soit corrigé, j'ai copié les images dans mon dossier source et j'utilise un marqueur personnalisé - l'omission des informations sur la taille/l'emplacement semble être ok...

        var customDefault = L.icon({
            iconUrl: 'images/marker-icon.png',
            shadowUrl: 'images/marker-shadow.png',
        });

Je voulais partager ce que j'ai fait pour contourner le problème data:url invalide. Fondamentalement, définissez l'icône par défaut sur une nouvelle qui utilise l'icône de marqueur et l'ombre fournies, mais laissera webpack gérer l'encodage des données de ces images individuellement. Incluez simplement un fichier comme celui-ci quelque part.

import L from 'leaflet';

import icon from 'leaflet/dist/images/marker-icon.png';
import iconShadow from 'leaflet/dist/images/marker-shadow.png';

let DefaultIcon = L.icon({
    iconUrl: icon,
    shadowUrl: iconShadow
});

L.Marker.prototype.options.icon = DefaultIcon;

Pourrait probablement être modifié pour inclure également l'icône de la rétine.

quelqu'un pourrait-il envoyer le fichier modifed leaf.js ?
le code que @ajoslin103 utilise :
```var customDefault = L.icon({
iconUrl : 'images/marker-icon.png',
shadowUrl: 'images/marker-shadow.png',
});

Je n'ai pas modifié le fichier brochure.js, j'ai juste copié les images de marqueur de la distribution de la brochure dans mon dossier d'images normal, puis j'ai utilisé ce fragment que j'ai posté comme icône personnalisée.

Je n'ai pas pu utiliser la solution de crob611 car ils étaient référencés dans le css d'origine en tant que http et mon site était desservi via https.

``` fonction onLocationFound(e) {
var rayon = e.précision / 2 ;
var customDefault = L.icon({
iconUrl : 'marker_icon_2x',
shadowUrl: 'marker_shadow.png'
});
L.marker(e.latlng).addTo(map)
.bindPopup("Vous êtes à " + rayon + " mètres de ce point").openPopup();
L.circle(e.latlng, radius).addTo(map);
}

comment puis-je définir la nouvelle icône ?

Je crée l'icône personnalisée dans mon constructeur (j'utilise le framework Aurelia)

        this.customDefault = L.icon({
            iconUrl: 'images/marker-icon.png',
            shadowUrl: 'images/marker-shadow.png',
        });

Ensuite, je l'utilise lorsque j'ajoute le marqueur dans la méthode attach()

        var map = L.map('mapid').setView([latitude, longitude], 13);
        let urlTemplate = 'http://{s}.tile.osm.org/{z}/{x}/{y}.png';
        map.addLayer(L.tileLayer(urlTemplate, { minZoom: 4 }));
        L.marker([latitude, longitude], { icon: this.customDefault }).addTo(map);

Réf : http://leafletjs.com/examples/custom-icons/

Jusqu'à ce qu'il y ait une bonne solution à ce problème, puis-je suggérer d'ajouter un avertissement d'exécution lorsque _getIconUrl() (ou autre) rencontre de manière inattendue une interface utilisateur de données, pointant vers une URL de problème Github via console.warn ou quelque chose comme ça.

Cela amènerait les personnes ayant le même problème au bon endroit et suggérerait des solutions de contournement (comme celle-ci qui a fonctionné pour moi).

C'est ainsi que React (dev builds) aide les développeurs à identifier les problèmes.

Du problème de réaction, une solution de contournement par @PTihomir

import L from 'leaflet';
delete L.Icon.Default.prototype._getIconUrl;

L.Icon.Default.mergeOptions({
  iconRetinaUrl: require('leaflet/dist/images/marker-icon-2x.png'),
  iconUrl: require('leaflet/dist/images/marker-icon.png'),
  shadowUrl: require('leaflet/dist/images/marker-shadow.png'),
});

cela résout le problème sans modifier les fichiers de base de la brochure.

@codeofsumit : Pour

La solution de contournement devra être ajustée au cas où Leflet nécessiterait (ou nécessitera à l'avenir) d'autres icônes de la même manière (peut-être pour d'autres composants - je ne sais pas).

Pour ceux qui ne connaissent pas Webpack : Webpack attribuera de nouvelles URL à ces propriétés :

/***/ 5305024559067547:
/***/ function(module, exports, __webpack_require__) {

    module.exports = __webpack_require__.p + "d95d69fa8a7dfe391399e22c0c45e203.png";

/***/ },


...


    _leaflet2['default'].Icon.Default.mergeOptions({
      iconRetinaUrl: __webpack_require__(5305024559067547),
      iconUrl: __webpack_require__(6633266380715105),
      shadowUrl: __webpack_require__(880063406195787)
    });

(les détails dépendent fortement de la configuration Webpack utilisée)

@jampy oui bien sûr. C'est donc une solution de contournement. Cependant, toute modification apportée au noyau de la brochure sera supprimée à chaque mise à jour. J'utiliserai la solution de contournement mentionnée jusqu'à ce qu'il y ait une solution appropriée car cela semble être la moins douloureuse.

Même problème ici, la fonction detectIconPath renvoie http://localhost:8080/2273e3d8ad9264b7daa5bdbf8e6b47f8.png") pour le chemin url("http://localhost:8080/2273e3d8ad9264b7daa5bdbf8e6b47f8.png")

c'est loin d'être idéal, mais j'utilise webpack et j'utilise cette solution de contournement

J'ai copié les images dans un dossier d'images à la racine de mon projet

puis dans mon package.json j'ai ajouté un script postbuild npm (dans la section scripts)
" postbuild:prod " : "./Post-Build4Prod.sh"

qui copie un dossier d'images dans la dist

#bin/bash
cp -r ./images ./dist/.

puis je définis un customDefault pour les icônes

    this.customDefault = L.icon({
        iconUrl: 'images/marker-icon.png',
        shadowUrl: 'images/marker-shadow.png',
    });

et l'utiliser partout

    L.marker([latitude, longitude], { icon: this.customDefault }).addTo(map);

@ ajoslin103 , envisagez cette solution de contournement . C'est plus simple et vous obtenez le même résultat.

J'ai utilisé ce qui suit pour contourner ce problème dans un projet de pack Web Vue :

import L from 'leaflet';

L.Icon.Default.imagePath = '/';
L.Icon.Default.mergeOptions({
    iconRetinaUrl: require('leaflet/dist/images/marker-icon-2x.png'),
    iconUrl: require('leaflet/dist/images/marker-icon.png'),
    shadowUrl: require('leaflet/dist/images/marker-shadow.png'),
});

J'ai eu le même problème avec collectstatic et CachedStaticFilesStorage de Django qui ajoute un hachage du contenu du fichier au nom des fichiers statiques, donc marker-icon.png devient marker-icon.2273e3d8ad92.png puis l'expression rationnelle à la fin de _detectIconPath ne correspond pas.

Je l'ai changé en replace(/marker-icon[^"']+\.png[\"\']?\)$/, '') qui a fonctionné pour moi.

J'ai aussi ce problème actuellement.
Utilisation de Leaflet 1.0.3 et Angular2.
J'avoue, je ne vois pas comment le résoudre étant donné ce fil.

Pour Angulaire 2 & 4
Je crée un fichier require.d.ts avec le code :

interface WebpackRequire {
    <T>(path: string): T;
    (paths: string[], callback: (...modules: any[]) => void): void;
    ensure: (paths: string[], callback: (require: <T>(path: string) => T) => void) => void;
}
interface NodeRequire extends WebpackRequire {}
declare var require: NodeRequire;

puis en utilisant exigerpour ce problème :

                  this.marker = L.marker(e.latlng, {
                    icon: L.icon({
                        iconUrl: require <any>('../../images/marker-icon.png'),
                        shadowUrl: require <any>('../../images/marker-shadow.png'),
                    })

Solution de contournement (avec taille et ancre) pour Vue.js avec webpack :

import L from 'leaflet'

// BUG https://github.com/Leaflet/Leaflet/issues/4968
import iconRetinaUrl from 'leaflet/dist/images/marker-icon-2x.png'
import iconUrl from 'leaflet/dist/images/marker-icon.png'
import shadowUrl from 'leaflet/dist/images/marker-shadow.png'
L.Marker.prototype.options.icon = L.icon({
  iconRetinaUrl,
  iconUrl,
  shadowUrl,
  iconSize: [25, 41],
  iconAnchor: [12, 41],
  popupAnchor: [1, -34],
  tooltipAnchor: [16, -28],
  shadowSize: [41, 41]
})

J'ai fait quelques tests de performances rapides pour incorporer l'icône par défaut en base64 par rapport à l'utilisation d'une URL d'image externe. Lors du chargement de _beaucoup_ de marqueurs (1000, dans mon cas), les performances sont nettement pires pour les images en ligne en base64.

Voici la vue des performances de Chrome devtools lors du chargement de 1000 icônes de marqueur en tant qu'URL externes :

En comparaison, avec 1000 icônes de marqueur en base64 inline (veuillez noter une échelle différente pour la chronologie, désolé):

Comme on peut le voir, pour une raison quelconque, la composition du calque est retardée lors de l'utilisation d'images en ligne, ce qui fait que le chargement complet prend environ une seconde de plus.

Pour une utilisation occasionnelle, cela n'a probablement pas d'importance, mais si vous utilisez beaucoup de marqueurs, cela peut être pertinent.

Une proposition pour gérer ce long terme :

• Correction #5041 pour résoudre les problèmes mentionnés dans la revue de code ; cela ferait fonctionner les icônes incorporées hors de la boîte
• Enregistrez un avertissement si des icônes intégrées sont utilisées, pour indiquer que cela pourrait ne pas être idéal

Une autre option serait de revenir à l'ancienne méthode (0.7) pour détecter le chemin de l'image, mais nous savons qu'il y avait d'autres problèmes que nous n'avons pas pu résoudre.

Salut @perliedman ,

Beau profilage !
Cela répond aux doutes que j'avais concernant la réutilisation des images en ligne.

En effet, le PR #5041 pourrait être remanié afin que Leaflet puisse fonctionner immédiatement lorsque les images d'icônes sont intégrées dans le CSS (par un moteur de construction comme webpack).
La solution à laquelle je peux penser (principalement similaire au PR mentionné) impliquerait la création d'une classe par image, ce qui augmenterait la taille du fichier CSS (et probablement JS) de quelques dizaines d'octets.

Exemple : http://playground-leaflet.rhcloud.com/dulox/1/edit?html ,css,output

Mais comme je l'ai mentionné précédemment , il est regrettable qu'un tel changement pour des raisons de compatibilité (avec les moteurs de build) affecte les utilisateurs qui n'utilisent pas ces frameworks et processus de build.

D'un autre côté, le résultat pourrait être "plus propre" puisque nous pourrions nous débarrasser des noms de fichiers codés en dur dans les options de classe IconDefault et déléguer le chemin complet (y compris le nom de fichier) au CSS.
C'est très intéressant car (si je comprends bien) le but de cette détection complexe est de découpler l'emplacement des images du fichier JS et de se fier à leur emplacement relatif au fichier CSS à la place. Par conséquent, il est logique pour moi que même le nom du fichier soit défini dans le CSS.

Mais essayer de maintenir la compatibilité avec l'option imagePath pourrait également être compliqué, car cela nécessiterait probablement de retravailler les chemins d'image précédemment détectés, pour remplacer le chemin principal et conserver le nom du fichier. Par conséquent, nous y introduirions une nouvelle RegExp.

Enfin, je ne suis pas sûr que cela couvrirait tous les cas.
Les processus de génération peuvent être hautement personnalisés, ce qui conduit à des situations très différentes concernant les actifs statiques tels que les images d'icônes. Il peut encore y avoir des cas extrêmes où même ce qui précède échouerait.

@ghybs J'aime cet exemple ( http://playground-leaflet.rhcloud.com/dulox/) !

Peut-être que vous en faites trop, mais que pensez-vous de spécifier également l'icône _size_ dans ce CSS (en utilisant width et height ) ? Je peux imaginer que quelqu'un outrepasse ces règles CSS pour changer l'icône par défaut, seulement pour découvrir qu'elle a maintenant les mauvaises dimensions.

Avec ou sans les dimensions en CSS, je pense que c'est une bonne voie à suivre. Souhaitez-vous faire un PR dans le sens de votre exemple ? Si vous n'avez pas le temps ou l'énergie en ce moment, je peux aller de l'avant et le faire, dites-moi simplement ce que vous préférez.

Je suis impatient de clore celui-ci, car il m'est arrivé de tomber moi-même sur ce problème.

Salut @perliedman ,

Je suis d'accord qu'il serait encore mieux de pouvoir spécifier la taille de l'icône via CSS.

Mais dans ce cas, par souci de cohérence, nous devrions également pouvoir spécifier le point d'ancrage. Je ne sais pas quelle règle CSS conviendrait pour cela (peut-être de la marge ?). Si c'est possible, alors le résultat serait très sympa je pense : les icônes seraient entièrement définies en CSS.

En poussant encore plus loin, cela pourrait être un moyen supplémentaire de définir une icône : spécifiez 3 classes CSS (icône, rétine, ombre) et Leaflet en extrairait toutes les options d'icône.

N'hésitez pas à travailler dessus, je ne sais pas quand je pourrai avoir du temps malheureusement...

S'appuyant sur l'exemple précédent, voici un concept de lecture des règles CSS padding et margin pour déterminer iconAnchor ( shadowAnchor ) et popupAnchor option :
http://playground-leaflet.rhcloud.com/xuvi/1/edit?html ,css,sortie

Je n'aime pas le fait que j'ai utilisé padding pour déterminer le iconAnchor , car à la fin Leaflet utilise margin pour positionner l'image de l'icône…
Mais c'est le plus simple que j'ai trouvé de spécifier rapidement les choses en CSS et d'éviter d'inverser les valeurs par rapport à la façon dont nous spécifions les options d'icône.

Bien que j'aime le résultat de tout spécifier en CSS, il reste encore du travail à faire pour maintenir la compatibilité descendante avec L.Icon.Default.imagePath .

Je m'excuse, je n'ai pas le temps de créer un PR.

Je viens de diagnostiquer un autre cas où _detectIconPath échoue : lors de l'utilisation de Firefox (testé avec ESR et les versions actuelles) et le réglage des Préférences → Contenu → Couleurs… → Remplacer les couleurs spécifiées par la page avec vos sélections ci-dessus : Toujours Firefox supprimera background-image propriétés dont celle de .leaflet-default-icon-path et ainsi casser _detectIconPath .

Je ne sais pas combien d'autres personnes utilisent cette fonctionnalité de Firefox, mais je l'utilise depuis très longtemps.

url() peut-il également être utilisé comme valeur d'autres propriétés CSS ? Comme utiliser le CSS suivant : .leaflet-default-icon-path { -leaflet-icon: url(images/marker-icon.png); } ou est-il impossible de définir et d'utiliser soi-même les propriétés CSS personnalisées ? Aucun navigateur n'aurait besoin de _comprendre_ la propriété -leaflet-icon , ils auraient cependant toujours besoin de la remplir et de rendre sa valeur disponible pour les scripts.

Salut @roques ,

Merci d'avoir signalé ce problème lors de l'utilisation de cette option spécifique dans Firefox !
On dirait que Chrome a une extension à contraste élevé mais qui ne change que les couleurs, sans rien casser dans Leaflet.

Malheureusement, Firefox supprime les propriétés CSS qu'il ne comprend pas.
Cependant, le type de données CSS de l' cursor , qui semble fonctionner correctement même lorsque le paramètre de remplacement des couleurs est utilisé dans Firefox :
http://playground-leaflet.rhcloud.com/yov/1/edit?html ,css,sortie

Je trouve moins élégant d'utiliser cursor au lieu de background-image , car son utilisation est bien plus éloignée de ce que l'on ferait pour faire un marqueur via le style CSS… mais de toute façon c'est déjà un hack pour le chemin détection uniquement.

J'étais sur le point de faire un PR pour résoudre le problème du pack Web, j'inclurai cette solution de contournement tout de suite.
Je n'ai aucune idée de comment nous pourrions faire un test automatisé pour ce cas, mais je pense que la solution de contournement devrait déjà être bonne.

Quelqu'un a-t-il trouvé une solution claire à ce problème ?

S'appuyant sur la réponse de @Shiva127 , pour toute personne utilisant Angular + Angular CLI :

Vous pouvez le mettre dans app.module.ts :

// BUG https://github.com/Leaflet/Leaflet/issues/4968
import {icon, Marker} from 'leaflet';
const iconRetinaUrl = 'assets/marker-icon-2x.png';
const iconUrl = 'assets/marker-icon.png';
const shadowUrl = 'assets/marker-shadow.png';
const iconDefault = icon({
  iconRetinaUrl,
  iconUrl,
  shadowUrl,
  iconSize: [25, 41],
  iconAnchor: [12, 41],
  popupAnchor: [1, -34],
  tooltipAnchor: [16, -28],
  shadowSize: [41, 41]
});
Marker.prototype.options.icon = iconDefault;

et ajoutez la ligne glob dans votre .angular-cli.json :

"assets": [
        "assets",
        "favicon.ico",
        { "glob": "**/*", "input": "../node_modules/leaflet/dist/images/", "output": "./assets/" }
      ],

Cela copiera les icônes dans le dossier assets du dossier dist au moment de la construction (vous ne les verrez pas dans src/assets). De plus, mettre le travail dans app.module.ts est un bon endroit pour conserver les importations globales de modification de prototype (telles que les correctifs observables RxJS). Avec cela, l'importation de Marker ailleurs dans la base de code fonctionnera correctement.

J'ai résolu ce problème comme ceci.

J'ai fourni une icône par défaut au marqueur drawOptions :

const myIcon = L.icon({
    ...
    ...
});

const drawOptions = {
      ....
      marker: {
         icon: myIcon
      }
};

...

Puis chemin enregistré vers l'icône sur L.Draw.Event.CREATED

this.map.on(L.Draw.Event.CREATED, (e) => {

      const layer: any = (e as L.DrawEvents.Created).layer;
      const type = (e as L.DrawEvents.Created).layerType;

      // Create a marker.
      if (type === 'marker') {

        let feature = layer.feature = layer.feature || {};
        feature.type = "Feature";
        feature.properties = feature.properties || {};
        feature.properties["markerIconsPath"] = "/assets/icons/";
       }
 });

Enfin, lors de l'affichage des calques, j'ai défini imagePath :

if(layer instanceof L.Marker) {
            L.Icon.Default.imagePath = layer.feature.properties.markerIconsPath;
            layer.setIcon(greenIcon);
 }

@codeofsumit ces correctifs sont-ils inclus dans la dernière version 1.3.1 ? Étonnamment, j'utilise la version 1.3.1 et je rencontre toujours le même problème.

@vishalrajole à ma connaissance, le seul PR soumis pour résoudre ce problème est le # 5041, qui est ouvert avec les modifications demandées depuis _long_ temps.

Nous avons aussi la solution alternative #5771, qui est sympa mais qui impliquait plus de changements.

Donc, pour résumer : personne n'a soumis de RP acceptée pour résoudre ce problème, l'aide est la bienvenue !

@perliedman d' après son apparence, les modifications impliquées de #5771 sont nécessaires. Sinon, vous continuerez à avoir ce problème dans différentes circonstances. Pourquoi ne pas simplement fusionner cela ?

Salut @mb21 ,

les modifications impliquées de #5771 sont nécessaires

En fait les changements proposés sont de 2 types :

• lire chaque chemin d'image au lieu de simplement l'emplacement du dossier images, de sorte que les URL modifiées par les moteurs de construction (comme le chargeur de fichiers webpack) soient lues telles quelles au lieu d'être reconstruites / devinées.
• lire toutes les autres options d'icônes par défaut à partir de CSS, de sorte que toute la configuration soit regroupée en un seul endroit.

Le 2ème point est intéressant si le 1er est incontournable, même s'il ajoute pas mal de code.

Le premier est en fait une faveur pour les développeurs utilisant un moteur de construction qui manipule les URL en CSS. Il garde Leaflet _zero config spirit_ même dans un nouvel environnement où le développeur passe pas mal de temps à régler sa configuration (si vous utilisez le chargeur de fichiers webpack, vous avez de toute façon besoin d'une configuration personnalisée), au détriment d'ajouter pas mal de code pour tout le monde, ce qui est l'esprit IMHO _contre_ Leaflet (prend en charge l'usage courant dans le noyau, délègue d'autres cas d'utilisation aux plugins).
Vous pouvez très facilement résoudre le problème en spécifiant les chemins d'accès aux images, généralement en utilisant require(image) comme indiqué dans les nombreux commentaires ci-dessus.

Par conséquent, même si j'ai écrit ce PR, je me sens personnellement mal à l'aise de le fusionner dans le noyau. Les changements _ne sont pas nécessaires pour la majorité_.

Ils sont bien sûr agréables pour faciliter la vie des développeurs, mais le problème est principalement causé par l'interaction des moteurs de construction / wrappers de framework, chacun ayant ses spécificités, et chacun ayant un moyen simple de dire à Leaflet où se trouvent maintenant les images, en utilisant le déjà existant API.

Peut-être devrions-nous plutôt aborder ce problème avec une meilleure documentation (par exemple une section dédiée à l'utilisation avec les moteurs de construction / frameworks ?), et/ou un plugin ?

Eh bien, je ne suis pas sûr de comprendre les subtilités. Mais ce serait bien pour toutes sortes de développeurs si _tous_ les chemins d'images pouvaient être spécifiés en CSS. Ce ne sont pas seulement les utilisateurs de webpack, ce sont aussi des gens comme moi qui utilisent le pipeline d'actifs Rails ou Django qui ajoute un hachage à chaque actif statique...

J'ai rencontré exactement le même problème :
data:image/png;base64,iVBORw0...AAAAASUVORK5CYII=")marker-shadow.png net::ERR_INVALID_URL

La solution est de remplacer :

getIconUrl: function (name) {
        if (!IconDefault.imagePath) {   // Deprecated, backwards-compatibility only
            IconDefault.imagePath = this._detectIconPath();
        }

        // <strong i="8">@option</strong> imagePath: String
        // `Icon.Default` will try to auto-detect the location of the
        // blue icon images. If you are placing these images in a non-standard
        // way, set this option to point to the right path.
        return (this.options.imagePath || IconDefault.imagePath) + Icon.prototype._getIconUrl.call(this, name);
    },

avec:

 // ...
  const url = (this.options.imagePath || L.Icon.Default.imagePath);

  return url.slice(0, -2);

comme suggéré par codeofsumit.

J'ai trouvé cela vraiment ennuyeux et le fait qu'il y ait un PR pour le réparer mais pas fusionné à cause du "sentiment" que "Les changements ne sont pas nécessaires pour la majorité". Désolé, mais j'ai vu des gens se débattre avec PHP, RoR, Python (Django) et node.js, alors où pensez-vous est "la majorité" au-delà de ces groupes ? Quel framework compatible recommanderiez-vous ?

Je suis d'accord avec @macwis

J'ai le même problème et ce fil est très long. Pourquoi ne pas fusionner le PR ?

Ce n'est pas un sentiment, c'est un fait : la majorité n'utilise aucun framework, ou ceux qui ne tripotent pas CSS.
La dernière fois que j'ai vérifié, Leaflet n'était pas 1 téléchargé à partir du CDN unpkg, c'est-à-dire CSS dégroupé et décrypté.

La bonne solution consiste à définir les options d'icône par défaut, comme expliqué dans de nombreux messages ci-dessus.
De nombreux frameworks le font dans le cadre de leur plugin d'intégration Leaflet.

Si vous souhaitez une solution plus automatique, vous avez toujours la possibilité de publier un plugin.

Pourquoi ne pas fusionner le PR ?

Lisez les commentaires, par exemple https://github.com/Leaflet/Leaflet/issues/4968#issuecomment -382639119

Je voudrais juste ajouter un petit indice : vous pouvez également utiliser CDN lorsque vous utilisez un framework. C'est ce que nous faisons par exemple avec notre React App. Nous chargeons de grandes bibliothèques via CDN.

@googol7 merci pour votre contribution.

Veuillez me corriger si je me trompe : si vous chargez Leaflet via le CDN, cela signifie très probablement que vous ne modifiez pas son CSS. Vos utilisateurs sont donc majoritaires.

@ghybs : Ce que je devais faire était le suivant :

// Workaround: https://github.com/Leaflet/Leaflet/issues/4968#issuecomment-269750768
/* eslint-disable no-underscore-dangle, global-require */
delete L.Icon.Default.prototype._getIconUrl

L.Icon.Default.mergeOptions({
    iconRetinaUrl: require("leaflet/dist/images/marker-icon-2x.png"),
    iconUrl: require("leaflet/dist/images/marker-icon.png"),
    shadowUrl: require("leaflet/dist/images/marker-shadow.png"),
})
/* eslint-enable no-underscore-dangle, global-require */

notre configuration webpack ressemble à ceci :

module.exports = {
    externals: {
        leaflet: "L",
    },
}

@googol7 merci pour les détails de ta config.

Vous voulez donc dire que vous chargez Leaflet JS à partir du CDN, mais regroupez le CSS et les images dans votre application.

@ghybs oui, je suppose que c'est ce qui se passe ici.

Assurez-vous de suivre les deux premières étapes : https://leafletjs.com/examples/quick-start/
J'ai eu un problème similaire car j'utilisais le css du tutoriel de quelqu'un d'autre, mais celui-ci doit être utilisé

<link rel="stylesheet" href="https://unpkg.com/[email protected]/dist/leaflet.css" integrity="sha512-Rksm5RenBEKSKFjgI3a41vrjkw4EVPlJ3+OiI65vTjIdo9brlAacEuKOiQ5OFh7cOI1bkDwLqdLw3Zg0cRJAAQ==" crossorigin=""/>

puis le script Leaflet immédiatement après cela

<script src="https://unpkg.com/[email protected]/dist/leaflet.js" integrity="sha512-/Nsx9X4HebavoBvEBuyp3I7od5tA0UzAxs+j83KgC8PU0kgB4XiK4Lfe4y4cgBtaRJQEIFCW+oC506aPT2L1zw==" crossorigin=""></script>

Salut tout le monde,

J'ai publié le plugin Leaflet " brochure-defaulticon-compatibility " qui reprend le code de mon PR https://github.com/Leaflet/Leaflet/pull/5771.
En utilisant ce plugin, l'icône par défaut de Leaflet n'essaie plus de reconstruire les chemins d'accès aux images d'icônes, mais repose entièrement sur le CSS. De cette façon, il devient entièrement compatible avec les moteurs de construction et les frameworks qui gèrent automatiquement les actifs basés sur CSS (et réécrivent généralement les url() ).

Chargez simplement le plugin (CSS + JS) _after_ Leaflet.
Par exemple dans le webpack :

import 'leaflet/dist/leaflet.css'
import 'leaflet-defaulticon-compatibility/dist/leaflet-defaulticon-compatibility.webpack.css'
import * as L from 'leaflet'
import 'leaflet-defaulticon-compatibility'

( démo )

Bien que je puisse comprendre que de nombreux développeurs auraient préféré que cette fonctionnalité soit incorporée directement dans le noyau de Leaflet, il a été avancé que le code ajouté est inutile pour la majorité des utilisateurs finaux. Par conséquent, m'alignant sur l'esprit Leaflet de garder son noyau simple, j'ai décidé d'en faire un plugin.

N'hésitez pas à ouvrir un problème sur le dépôt du

Le fait est que si vous utilisez webpack, vous rencontrez ce problème. Je vois la tendance de plus en plus de sites utilisant webpack. Placer cela en tant que plugin est loin d'être idéal, à mon humble avis, car je ne vois pas de personnes à la recherche d'un plugin pour résoudre ce genre de problème (un peu comme je l'ai fait lorsque j'ai ouvert un dup).
J'aimerais beaucoup voir ce dépliant à l'intérieur car il s'agit plus d'une correction de bogue que d'une fonctionnalité...

Si vous souhaitez résoudre ce problème dans Angular 6, écrivez simplement angular.json :

 {
         "glob": "**/*",
         "input": "./node_modules/leaflet/dist/images/",
         "output": "./assets/leaflet/"
  }

Après cela, remplacez le comportement par défaut de Marker , comme le suggèrent certaines des réponses précédentes :

import { Icon, icon, Marker, marker } from 'leaflet';

@Component({
   selector: 'app-something',
   templateUrl: './events.component.html',
   styleUrls: ['./events.component.scss']
})
export class SomeComponent implements OnInit {
  // Override default Icons
  private defaultIcon: Icon = icon({
    iconUrl: 'assets/leaflet/marker-icon.png',
    shadowUrl: 'assets/leaflet/marker-shadow.png'
  });

  ngOnInit() {
     Marker.prototype.options.icon = this.defaultIcon;
  }
}

Le package angulaire que j'ai utilisé et qui a eu le même problème qu'ici est : ngx-leaflet

REMARQUE:
Il est petit à prise angulaire 6, comme réponse de _t.animal_ sur StackOverflow dit

Sachez que dans Angular 6, il existe deux constructeurs build et test .

Assurez-vous de le mettre sous build .

@marko-jovanovic merci pour l'info, mais que se passe-t-il si je n'utilise pas ces actifs et que je souhaite réduire la taille de mon colis ?
Votre suggestion relève toujours de ma définition d'une solution de contournement, l'OMI.

@HarelM Eh bien, je ne pouvais pas venir avec une autre solution car j'étais pressé de terminer le projet d'école. Ce n'est pas parfait et je sais que cela augmente la taille du paquet, mais ma solution me suffisait et j'espérais que ma réponse pourrait aussi aider les autres d'une manière ou d'une autre.

@marko-jovanovic votre solution est excellente et j'espère aussi qu'elle pourra aider les autres. J'espère juste une solution, pas une solution de contournement :-)

@marko-jovanovic Salut, je suis trop assis sur un projet scolaire (Angular 6) et je ne peux pas comprendre pourquoi les choses ne fonctionnent pas pour moi. Pour être honnête, je suis un noob total pour tout ce genre de choses ici.

Lorsque j'insère votre code dans la ngOnInit -Function de mon composant, il renvoie une erreur à la partie où vous définissez iconUrl et shadowUrl :

Argument of type '{ iconUrl: (options: IconOptions) => Icon<IconOptions>; shadowUrl: any; }' is not assignable to parameter of type 'IconOptions'. Types of property 'iconUrl' are incompatible. Type '(options: IconOptions) => Icon<IconOptions>' is not assignable to type 'string'.

Est-ce que j'ai raté quelque chose ? Merci d'avance!

@gittiker J'ai mis à jour une réponse avec les exemples d'importation, de composant et de ngOnInit. Faites-moi savoir si tout s'est bien passé. :)

@gittiker J'ai mis à jour une réponse avec les exemples d'importation, de composant et de ngOnInit. Faites-moi savoir si tout s'est bien passé. :)

Oui merci beaucoup, ça marche enfin. J'ai dû manipuler un peu votre URL donc c'est
'assets/leaflet/images/marker-icon.png au lieu de 'assets/leaflet/marker-icon.png', . Idem pour l'image d'ombre.

@ crob611 Merci beaucoup, j'ai essayé de résoudre le problème avec cette méthode.

@marko-jovanovic tu m'as sauvé ! mais comment @HarelM dit, n'y a-t-il pas une solution ?

merci beaucoup, mais pour moi il a servi le code suivant : (Angular 6 et dépliant1.3.4)
Premier pas
(https://codehandbook.org/use-leaflet-in-angular/)
Mais alors l'icône n'a pas été affichée
erreur obtenir l'image de l'icône
net :: ERR_INVALID_URL
le résoudre en insérant le code suivant dans le composant
supprimer L.Icon.Default.prototype._getIconUrl;`

L.Icon.Default.mergeOptions({
  iconRetinaUrl: '/assets/leaflet/dist/images/marker-icon-2x.png',
  iconUrl: '/assets/leaflet/dist/images/marker-icon.png',
  shadowUrl: '/assets/leaflet/dist/images/marker-shadow.png',
});`

Solution utilisant le feuillet 1.3.4 avec vue2-leaflet 1.2.3 :

import { L, LControlAttribution, LMap, LTileLayer, LMarker, LGeoJson, LPopup } from 'vue2-leaflet'
delete L.Icon.Default.prototype._getIconUrl
L.Icon.Default.mergeOptions({
  iconRetinaUrl: require('leaflet/dist/images/marker-icon-2x.png'),
  iconUrl: require('leaflet/dist/images/marker-icon.png'),
  shadowUrl: require('leaflet/dist/images/marker-shadow.png')
})

Mes 2 centimes : mon problème avec webpack était juste dû aux noms de fichiers hachés, j'ai donc configuré file-loader afin de ne pas hacher les images du dépliant :

use: [{
    loader: 'file-loader',
    options:
      {
        name(file) {
          console.log(file)
          if (file.match(/(layers-2x\.png|layers\.png|marker-icon\.png|marker-icon-2x\.png|marker-shadow\.png)/)) {
            return '[name].[ext]'
          }

          return '[name]-[hash].[ext]'
        },
        context: 'app/frontend' // <-- project specific
      }
  }]

AFAIK grossier mais efficace.

@ghybs merci pour le correctif. J'ai rencontré ce bug à plusieurs reprises dans différents projets. Tout ce fil semble absurde que ce ne soit pas corrigé ou qu'il ne soit pas considéré comme un problème.

google m'a amené ici car l'utilisation de la bibliothèque avec Webpack me donnait cette erreur.

Est-ce que quelqu'un sait pourquoi ces images ne sont pas intégrées au format svg ?

Je pense que cela pourrait facilement être résolu avec postcss et postcss-inline-svg . Les icônes deviendraient des fichiers svg en ligne au lieu de png externes. Les icônes seraient plus nettes à mesure que ce problème disparaîtrait.

Est-ce que quelqu'un sait pourquoi ces images ne sont pas intégrées au format svg ?

Prise en charge des navigateurs hérités.

Merci @IvanSanchez

Ensuite, je vois deux solutions potentielles. L'une consiste à insérer les images au format .png encodées en base64 . L'autre alternative consiste à insérer des icônes .svg et à faire en sorte que les développeurs qui ciblent les plates-formes héritées remplacent les icônes par défaut.

L'une de ces solutions vaut-elle une pull request ?

Parmi tous les navigateurs pris en charge par brochure , les suivants ne prennent pas en charge svg ( caniuse ).

• IE 7 et 8
• Navigateur Android 2.*

inline les images en base64

Voir https://github.com/Leaflet/Leaflet/issues/4968#issuecomment-322422045

J'ai dû ajouter une ancre et une taille aussi pour que cela fonctionne, par exemple

   import icon from 'leaflet/dist/images/marker-icon.png';
   import iconShadow from 'leaflet/dist/images/marker-shadow.png';

   let DefaultIcon = L.icon({
      iconUrl: icon,
      shadowUrl: iconShadow,
      iconSize: [24,36],
      iconAnchor: [12,36]
    });

    L.Marker.prototype.options.icon = DefaultIcon; 

J'ai également le même problème (webpack utilisant Flask, donc tous les éléments sont censés être dans un dossier statique), mais le correctif @giorgi-m n'est pas suffisant, car j'obtiens une erreur "" les exportations " sont en lecture seule " ( Firefox, semble-t-il lié aux importations de png ?).
Je vois que le problème est clos, mais nous voyons toujours des problèmes avec la 1.4.0, alors je me demande quel est le correctif ?

Voir ce problème avec vue2-leaflet 2.0.2 et le dépliant 1.4.0.

cela semble exister depuis un certain temps, et la moitié des solutions présentées ne semblent pas fonctionner.

Quelqu'un a-t-il trouvé l'origine de ce problème ?

j'ai le même problème avec les versions "vue2-leaflet": "2.0.3" dépliant "leaflet": "1.4.0".

exécutant également webpack.

Nous utilisons avec succès vue2-leaflet 2.0.3 et le dépliant 1.4.0 en utilisant une solution trouvée dans ce même problème :

import L from 'leaflet'
require('../../node_modules/leaflet/dist/leaflet.css')

// FIX leaflet's default icon path problems with webpack
delete L.Icon.Default.prototype._getIconUrl
L.Icon.Default.mergeOptions({
  iconRetinaUrl: require('leaflet/dist/images/marker-icon-2x.png'),
  iconUrl: require('leaflet/dist/images/marker-icon.png'),
  shadowUrl: require('leaflet/dist/images/marker-shadow.png')
})

Je suppose que la meilleure question qui doit être posée est pourquoi cela n'a pas été corrigé avec le code fusionné qui a provoqué la fermeture du problème. Puisqu'une solution de contournement qui fonctionne est excellente, mais cela devrait fonctionner immédiatement et doit toujours être un problème ouvert.

Chers tous,

Le dépliant fonctionne immédiatement.

Webpack (et d'autres moteurs de construction) combiné à Leaflet ne fonctionne pas immédiatement.

Veuillez vous référer à la solution proposée dans https://github.com/Leaflet/Leaflet/issues/4968#issuecomment -399857656 : brochure- defaulticon

Bien que je puisse comprendre que de nombreux développeurs auraient préféré que cette fonctionnalité soit incorporée directement dans le noyau de Leaflet, il a été avancé que le code ajouté est inutile pour la majorité des utilisateurs finaux. Par conséquent, m'alignant sur l'esprit Leaflet de garder son noyau simple, j'ai décidé d'en faire un plugin.

Avec webpack, une autre solution type , une fois vos loaders configurés :

import L from 'leaflet';
delete L.Icon.Default.prototype._getIconUrl;

L.Icon.Default.mergeOptions({
  iconRetinaUrl: require('leaflet/dist/images/marker-icon-2x.png'),
  iconUrl: require('leaflet/dist/images/marker-icon.png'),
  shadowUrl: require('leaflet/dist/images/marker-shadow.png'),
});

Il existe d'autres solutions proposées plus haut dans ce fil pour d'autres moteurs de construction et combinaisons de frameworks.

Pour éviter que ces solutions ne soient davantage enfouies sous les commentaires, je vais verrouiller ce fil.

Merci à tous pour les solutions partagées ! :+1: