Der Tag Result oder ResultValue bezieht sich immer auf den darüber liegenden Plan. Auf erster Stufe also auf den Master. In tieferen Stufen auf den darüber liegenden Detailplan.
Nein – das ist nicht möglich. Für diesen Fall muss ein DataExecutionPlan verwendet werden, der sich auf eine Ebene bezieht, die dieses Feature nutzt.
Ja – dazu ist an der „SingleComparison“ das Attribut „compareBehavior“ mit dem Wert „CompareStringsCaseInSensitiv“ zu belegen.
<SingleComparison compareBehavior="CompareStringsCaseInSensitiv">...</SingleComparison>
Es ist beides das Gleiche und hier nur unterschiedlich benannt. Png im RenderMap meint Png24(bit). Ein Umbenennen im Nachgang ist schwierig (ebenso wie bspw. von „<ExcecutionPlan>“), da damit alle bisher erstellten Button-Pläne nicht mehr funktionieren würden.
Diese Methode gibt an, ob beim Bestimmen eines Maßstabs aus der übergebenen Liste der Kartenausschnitt auch abgeschnitten werden kann oder lieber vergrößert werden soll.
Problem: Die Umsetzung erfolgt derzeit nicht, da es sich hier um einen Programmierfehler handelt. Wir werden dies korrigieren.
Die Umsetzung als weitere Funktion in den Extensions wäre möglich.
Dies wäre allerdings nur relevant für cardo-Instanzen, die mit NT-Authentifizierung eingerichtet sind. Für andere Installationen wäre auch das Auslesen der Beschreibung des Nutzers möglich (Hier müssten Sie prüfen, ob dies sinnvoll gefüllt ist.).
Sobald die imageSizeLargestEdge hinterlegt wird, verändert sich die physische Größe des Bildes. Das Kartenbild wird dann von IWAN so generiert, dass die längste Kante des Bildes diesem Wert in Pixeln entspricht. Die andere Kante wird dann im Verhältnis ermittelt.
Die Angaben imageWidth und imageHeight werden dann nur noch als „logische Größen“ intern verwendet, um die Pixel je Meter zu bestimmen und damit den Maßstab zu ermitteln bzw. in den Symboleinstellungen verwendet zu werden.
Wenn das erzeugte große Bild dann im PDF in einen kleineren Ausschnitt eingebettet wird, steigt damit die Auflösung des Bildes im Druck.
Dazu ist die Bildgröße in der Ausgabe zum Einen auf die Breite des tatsächlich angeforderten Bildes zu setzen. Weiterhin ist diese dann umzurechnen, da das Kartenbild von IWAN für eine 80DPI – Auflösung ausgelegt ist, ein Druck in der Regel aber in 96DPI erfolgt. (http://www.cardogis.com/?pgId=724 – unten). Weiterhin muss der Nutzer, der das Blatt dann ausdruckt, noch einige Sachen beachten, auf die der Planersteller keinen Einfluss mehr hat (http://www.cardogis.com/?pgId=1107).
gesamte Meldung:
Meldung: Die Planausführung schlug fehl. True. True Weitere Details: XslTransformException: Fehler während eines Aufrufs der Erweiterungsfunktion 'MapModifyBBoxZoomToGeom'. In 'InnerException' finden Sie eine vollständige Beschreibung des Fehlers. InvalidOperationException: Fehler beim Deserialisieren des Typs RenderMapArguments_Type. Die zugrundeliegende Fehlermeldung lautet: Fehler im XML-Dokument. Quelle: StringToNumber(): Die Eingabezeichenfolge hat das falsche Format. bei IDU.cardo3.CoreModules.Button.ExecutionPlan.__Execute(MainObject cMo, Dictionary`2 vars, PlanExecuteFilterBase filter, IButtonPlanStateManager stateManger) bei IDU.cardo3.CoreModules.Button.ExecutionPlan.Execute(MainObject cMo, Dictionary`2 vars, PlanExecuteFilterBase filter, IButtonPlanStateManager stateManger) bei Button_defaultApp.RunPlan(AxPlan planProps), ExceptionType: PlanExecutionFailedException, InnerException: bei IDU.cardo3.CoreModules.Button.ExecutionPlan.__Execute(MainObject cMo, Dictionary`2 vars, PlanExecuteFilterBase filter, IButtonPlanStateManager stateManger) bei IDU.cardo3.CoreModules.Button.ExecutionPlan.Execute(MainObject cMo, Dictionary`2 vars, PlanExecuteFilterBase filter, IButtonPlanStateManager stateManger) bei Button_defaultApp.RunPlan(AxPlan planProps), Stacktrace: Fehler während eines Aufrufs der Erweiterungsfunktion 'MapModifyBBoxZoomToGeom'. In 'InnerException' finden Sie eine vollständige Beschreibung des Fehlers.
Ursache:
Der Fehler ist bereits vorher mit der Definition der Kartenparameter entstanden:
<!--Kartenparameter für die Hauptkarte-->
<xsl:variable name="MapParameter">
<iXRH:RenderMap imageHeight="300"
imageWidth="300"
epsgCode="25832"
imageSizeLargestEdge="700">
<iXRH:Layer layerName="L1408">
<iXRH:Filter>
<iXRH:SingleComparison>
<iXRH:ColumnName>Objectid</iXRH:ColumnName>
<iXRH:Is>Equal</iXRH:Is>
<iXRH:Value>
<iXRH:Int>
<xsl:value-of select="/ButtonRow/Flurstueck/Objectid"/>
</iXRH:Int>
</iXRH:Value>
</iXRH:SingleComparison>
</iXRH:Filter>
</iXRH:Layer>
</iXRH:RenderMap>
</xsl:variable>
Laut XML Dokument muss dieser Pfad /ButtonRow/Flurstueck/objectid (objectID muss kleingeschrieben werden) lauten. Die XPath-Angaben sind case-sensitiv!
Wenn der XPath leer ist (also nichts gefunden wird), wird dort praktisch ein Leerstring in den Filter eingetragen und LeerString To Number bringt die o.g. Fehlermeldung.
Durch die Meldung davor „Fehler beim Deserialisieren des Typs RenderMapArguments_Type.“ ist die Stelle schon ziemlich stark eingegrenzt – muss auf alle Fälle interhalb des RenderMap-Nodes sein.
Es muss der Parameter SetPageSizeByName() mit der entsprechenden AX - Angabe aufgerufen werden.
Im HTML müsste dann geprüft werden: ob die Breiten alle relativ sind (style="width: 50%" statt style="width: 8.5cm").
Alternativ kann auch um das ganze HTML drumrum ein Choose-When-Block gesetzt werden und eine HTML-Ausgabe für A4 und eine ganz andere für A3 etc. zusammengestellt werden.
Das physische Bild von IWAN wird nicht größer als ca 2500px an der längsten Kante werden - je nach konkreter Einstellung auf Ihrem Server. Das ist das Maximum. Eine Anpassung des imageWidthLargestEdge würde keine weitere Änderung haben.
Wenn komplett auf A3 gedruckt werden soll, so sind das 2500px auf 420mm (5px pro mm).
Alternativ könnten auch mehrere Kartenbilder erzeugen und die Bilder im HTML dann zusammensetzen werden. Die Umsetzung im XLST würde komplexer werden. Hier muss dann für jedes Kartenbild die BBox berechnet werden etc...
Kommt bei der Ausführung eines Buttonplans die Meldung '... Nicht genügend Arbeistspeicher.' oder eine andere Meldung, welche innerhalb der HiQPdf-Bibliothek auftritt und auf nicht ausreichende Resourcen schließen lässt, dann kann die Erstellung des PDF in einen eigenen Prozess ausgelagert werden. Damit stehen für das Rendern mehr Resourcen zur Verfügung.
Die Auslagerung kann über einen Dienst erfolgen, der aber noch nicht im cardo-Update enthalten ist. Wir stellen die für den Dienst benötigten Dateien auf Anfrage zur Verfügung.
Um die PDF-Generierung in einem eigenen Prozess laufen zu lassen sind folgende Schritte nötig:
Aktuelle Einschränkungen:
Bei der Ausführung eines Button-Plan erhält der Nutzer unten angefügte Fehlermeldung. Der Nutzer hat das Recht, die Anwendung zu starten und am Verzeichnis, in welchem der Button-Plan abgelegt ist, das Recht „Browse“. Müssen noch weitere Berechtigungen eingerichtet werden? Welche Rechte müssen an den Ebenen vergeben sein, die im Button-Plan verwendet werden?
Zusätzlich benötigt der Nutzer an jeder Ebene, welche im Button-Plan genutzt wird die Berechtigungen Rendern von Geodaten, Zugriff auf Sachdaten.
Meldung: Ein Problem trat auf. Die Planauführung schlug fehl. True. False Weitere Details: FileNotFournException: Die Datei.... konnte nicht gerunden werden. ...
Prüfen Sie, ob der Ordner, in welchem der Button Plan liegt im VirtualDir Verzeichnis freigegeben ist und ob der jeweilige Nutzer die nötigen Berechtigungen besitzt, siehe 2. Freigabe der Buttonverzeichnisse über den VDir Manager