<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hallo Jürgen,</p>
    <p>jetzt hatte ich etwas Muße, mir Deinen Trigger-Code näher
      anzuschauen.</p>
    <p>Den Code an sich kann ich mit meinen wenigen SQL-Kenntnissen
      nachvollziehen und auch relativ gut verstehen, was er tun soll.
      Danke für's Bauen!<br>
    </p>
    <p>Wenn ich diesen in <span style="white-space: pre-wrap">preprocessing.d/2_transform.sql speichere und das alkis-import-tool starte, um ALKIS-Daten aus Sachsen-Anhalt (ST) mit EPSG: 25832 in eine bestehende Datenbank mit ALKIS-Daten aus Brandenburg (BB) mit EPSG:25833 zu integrieren, dann erscheint nach den ganzen Triggermeldungen im Protokoll dann doch eine Fehlermeldung (EXITCODE: 3) und nicht nur </span><span
      style="white-space: pre-wrap">preprocessing.d/2_transform.sql ist dann gescheitert, sondern auch </span><span
      style="white-space: pre-wrap">der gesamte Integrations-Prozeß bricht ab, auch, wenn ich z.B. den Haken bei "Alle Importfehler ignorieren" oder "COPY benutzen" raus nehme.</span></p>
    <p><span style="white-space: pre-wrap">Kann ich hier im Forum die Protokoll-Datei irgendwie hochladen oder gar den Text hier einkopieren? Vielleicht ist es ja nur eine Kleinigkeit, die geändert bzw. angepaßt werden muß.</span></p>
    <p><span style="white-space: pre-wrap">Der Micha</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <div class="moz-cite-prefix">Am 22.07.24 um 18:17 schrieb Jürgen E.
      Fischer via NAS:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20240722161743.ro4jbljh7f7j473e@norbit.de">
      <pre class="moz-quote-pre" wrap="">Moin Micha,

On Mon, 22. Jul 2024 at 17:32:34 +0200, Der Laie via NAS wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Am 22.07.24 um 17:16 schrieb Jürgen E. Fischer via NAS:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Im ALKIS-Import ist es nur nicht vorgesehen Daten aus anderen
Koordinatensystemen als denen der Datenbank zu importieren.
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Ah, verstehe, Jürgen,

es scheint also zwei Möglichkeiten zu geben:

1. ALKIS-Import umbauen
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Am 21.07.24 um 18:24 schrieb Jürgen E. Fischer via NAS:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Ich würde das über einen Trigger (ähnlich wie bei "Duplikate ignorieren")
regeln, der die Geometrie der Bundesländer, die vom Koordinatensystem der
Datenbank abweichen darauf transformieren.
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Ein SQL-Skript preprocessing.d/1_transform.sql zu ergänzen, würde ich nicht als
"umbauen" bezeichnen:

SET search_path TO :"alkis_schema",public;

CREATE OR REPLACE FUNCTION inplace_transform() RETURNS TRIGGER LANGUAGE plpgsql AS $$
BEGIN
  IF substr(NEW.gml_id, 3, 2) IN ('BW','BY','HB','HE','HH','NI','NW','RP','SH','SL','ST','TH') THEN
    NEW.wkb_geometry := st_transform(st_setsrid(NEW.wkb_geometry, 25832), 25833);
  END IF;
  RETURN NEW;
END;
$$ SET search_path TO :"alkis_schema";

SELECT format(E'DROP TRIGGER IF EXISTS %I ON %I.%I;\nCREATE TRIGGER %I BEFORE INSERT ON %I.%I FOR EACH ROW EXECUTE PROCEDURE inplace_transform();',
        a.table_name || '_transform', a.table_schema, a.table_name,
        a.table_name || '_transform', a.table_schema, a.table_name)
    FROM information_schema.columns a
    JOIN information_schema.columns b ON a.table_schema=b.table_schema AND a.table_name=b.table_name AND b.column_name='wkb_geometry'
    WHERE a.table_schema=:'alkis_schema'
      AND substr(a.table_name,1,3) IN ('ax_','ap_','ln_','lb_','au_','aa_')
      AND a.column_name='gml_id';
\gexec

Setzt voraus, dass die Datenbank in 25833 ist und tranformiert die Daten aus
"anderen" Bundesländern dorthin.  Getestet habe ich das allerdings nicht.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">oder
2. die xml-Dateien mit ogr2ogr in ein anderes CRS umzuwandeln
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">richtig?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Und meine Frage ist dann zu 2.: wie lautet der Konsolenbefehl, denn bei
mir hat folgender nicht geklappt:

|ogr2ogr -f "GML"output_file.xml input_file.xml -s_srs EPSG:25832 -t_srs
EPSG:25833 ERROR 1: No schema information loaded Der Micha |
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
So einfach geht das wahrscheinlich nicht - OGR bricht die GML-Daten ja erstmal
auf Layer und Attribute herunter und müßte die GML-Datei daraus wieder
aufbauen.  Ich würde daher nicht erwarte, dass dabei nur die Geometrien
verändert werden.

Dafür müßte man den ogr2ogr-Aufruf in ALKIS-Import modifizieren.


Jürgen

</pre>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
NAS mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NAS@lists.osgeo.org">NAS@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/nas">https://lists.osgeo.org/mailman/listinfo/nas</a>
</pre>
    </blockquote>
  </body>
</html>