Iconpfad in draw Modul

[Stolz]

Hallo zusammen,

in D:\masterportal_2.8.0\src\utils\convertFeaturesToKml.js
und
D:\masterportal_2.8.0\src\utils\convertFeaturesToKml.js
wird für den Iconpfad ${window.location.origin} benutz.
Das funktioniert nicht so wie erwartet.
Besser wäre hier vielleicht der Pfad aus Config.wfsImgPath?

Statt:
${window.location.origin}/img/tools/draw/circle_${getIconColor(pointColors[i])}.svg,
besser?
const iconUrl = Config.wfsImgPath + "/circle_" + ${getIconColor(pointColors[i])}.svg,

Dann funktioniert auch der Import und Druck.

Getestet in 2.8.0

Danke&VG

D. Stolz

[Dennis Sen]

Hallo Herr Stolz,

hier einmal ein Zwischenstand:

Ich habe das Thema beim LGV angesprochen und dass diese Bilder nicht im wfsImgPath liegen ist erstmal Absicht. Sie gehören als “Toolbestandteil” zum Masterportallieferumfang, ähnlich wie der MapMarker. Da sie immer da sein sollen, werden sie bisher nicht in eine separate portalspezifische Bildquelle ausgelagert.

Der LGV nimmt das Thema jedoch mit, um sich das einmal genauer anzuschauen – also welche Auswirkungen die Verschiebung auf Buildstrecke, Auslieferung, und Entwicklungsumgebung hätte. Dass dadurch der Druck sofort funktioniert, wäre ja ein Argument dafür. (Ansonsten müsste das Tool im Rahmen von z.B. auch #581 anderweitig gefixed werden.)

Viele Grüße

[Stolz]

Hallo Herr Sen,

das Problem betrifft ja eigentlich nur die circle_*.svg Icons im draw Modul.

Die anderen, selbst definierten Icons kann ich in der config.json in der draw iconList mit path definieren und sind von der Problematik nicht betroffen.

Wenn der der wfsImgPath nicht genutzt werden soll (was mit ihrer Argumentation sicherlich sinnvoll ist) vielleicht “einfach” im draw-Modul für den “simple_point” noch einen Pfad setzen pder ?

                "iconList": [
                {
                    "id": "iconPoint",
                    "type": "simple_point",
                    "value": "simple_point",
                    "path": "../img"
                },

Danke für’s kümmern.

Dietmar Stolz

[Dennis Sen]

Hallo Herr Stolz,

die Lösung ist leider nicht so einfach, da es dadurch zu weiteren Unstimmigkeiten kommen könnte. Einige davon sind mir erst jetzt beim erneuten Reinschauen aufgefallen.

Etwa beruht die “simple_point”-Darstellung beim Zeichnen direkt auf OpenLayers-Styles und erzeugt die Graphik zuerst code-seitig. Erst beim Exportieren werden dann die statischen SVGs referenziert. Deswegen sind sie wohl auch so “hart verdrahtet”, denn eine Änderung der SVGs würde sich beim Zeichnen gar nicht auswirken, erst in der KML und bei folgenden Imports. Dann hätte man wieder den Schiefstand, dass der Import potenziell anders aussieht als das Gezeichnete.

Eine konfiguratorische Lösung könnte sein, dass, wenn die SVGs auf einem anderen Pfad liegen sollen, man diese einzeln als Icons konfiguriert. Das ist dann zwar einmalig etwas mühselig, funktioniert aber wie erwartet.

Alternativ könnten wir das Thema auch noch mal zum Start aufrollen: Sie hatten geschrieben, dass `convertFeaturesToKml` nicht wie erwartet funktioniert, und mit der Änderung Import und Druck laufen. Ich habe jetzt im Dev-Stand und auf einem aktuellen Produktivstand aber keine Fehler nachvollziehen können. Ist hier ggf. etwas in einer neuen Version bereits repariert? Wenn nicht, würden mich die vollständige Konfiguration und Version (oben stehen 2.7.2 und 2.8.0) interessieren, dann kann ich das näher untersuchen.

Viele Grüße

[Stolz]

Hallo Herr Sen,

arbeite aktuell mit 2.19. Das Problem besteht aber seit Anbeginn, bei allen Usern.

Problem besteht nur dann wenn die simple_point-Icons nicht unter ${window.location.origin}/img/tools/draw/circle_${getIconColor(pointColors[i])}.svg abgelegt sind.

simple_point SVG-File nur für Export benutzt ist irgendwie doppelt angepackt.
Das erklärt warum simple_points nach einem kml-convert und reimport immer etwas anders aussehen (Größe stimmt nicht wirklich).

Würde die simple_point wie die anderen Icons handeln, mit Pfad, ohne initiales create via OL-Style.
Oder - wenn das zu viel Aufwand ist : simple_points in der Auswahlliste/Oberfläche deaktivieren können via config. Dann kann jeder mit ausschließlich eigenen Icons arbeiten.

Danke&VG

D. Stolz

[Dennis Sen]

Hallo Herr Stolz,

da die SVGs für diese Position mit ausgeliefert werden, würde ich deren Fehlen nicht als Bug fassen. Damit das Draw-Tool auch komplett ohne simple_point funktioniert, habe ich diesen PR erstellt:

https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3277/issue-605-fix-draw-without-simple_point

Es reicht dann ab der nächsten Version, wenn unter draw.iconList kein Eintrag mehr mit simple_point-Konfiguration auftaucht.

Eine weitere Änderung würde ich unter dem Issue-Typen “Proposal” sehen. Soll ich dann nach Merge dieses Issue auf Proposal umstellen? Gern können Sie für einen Verbesserungsvorschlag auch ein neues Issue erstellen, dann würde ich dieses hier schließen.

Viele Grüße

[Stolz]

Hallo Herr Sen,

für mich/Köln perfekt, Danke.

Kann dann die simple_points als Icons vom Typ “image” anbieten.

Das Issue können Sie gerne auf “Proposal” setzen obwohl ja die Umsetzung bereits technisch erfolgt ist. Als “Feature” geht’s ja auch nicht mehr?

Jedenfalls vielen Dank.

Dietmar Stolz

[Dennis Sen]

Hallo Herr Stolz,

ach so, ich hatte gedacht, dass Sie noch weiter eine Veränderung der Bildersituation im Masterportal vorantreiben möchten. Aber wenn damit schon alles passt, kann das ruhig als Bugticket stehen bleiben. Am Ende wurde ja auch ein Bug behoben.

https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3277/issue-605-fix-draw-without-simple_point

Der PR wurde nun gemerged und ab der nächsten Version funktioniert das Draw-Tool dann auch ohne simple_point.

Viele Grüße