<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.E-MailFormatvorlage18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=DE link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hallo zusammen,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>ich möchte hier die Diskussion über die Georeferenzierung einer DXF-Datei aus der englischen Mailingliste [1] aufgreifen. Und noch einmal an die kurze Diskussion, bzw. Anregung vom Andreas, während unserer letzten QGIS-DE-Vereinssitzung erinnern. Ich persönlich finde das Thema sehr wichtig und habe nur deshalb (mit QGIS) kein Problem, da ich diese Transformationen in der (Vermessungs-)CAD vornehme.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bernd hat zwar recht, dass die Ursache des Problems beim Ersteller der DXF-Daten liegt. Aber meine Erfahrung (> 25 Jahre) als Schnittstelle zwischen Planer und Vermesser, bzw. jetzt als GIS-Betreuer ist die, dass sich ein Teil der Architekten bewusst nicht um ein Koordinatensystem kümmert. Gerade kleinere Büros arbeiten oft mit veralteten Programmen, können manchmal noch nicht einmal die korrekten Koordinaten aufgrund ihrer Stellenanzahl in ihre CAD einlesen (ist zum Glück selten geworden) und wenn sie die Daten einlesen, dann setzen sie den Bezugspunkt erst einmal auf 0/0. <o:p></o:p></p><p class=MsoNormal>Das Problem wird zwar besser (insbesondere bei den größeren Büros) aber wird uns noch eine Weile erhalten bleiben.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In Zeiten von UTM haben die Planer auch ein wirkliches Problem, denn ihre geplante 100m lange Halle ist in Wirklichkeit keine 100m lang (Maßstabsfaktor bei UTM). Deshalb arbeiten hier in BW die mir bekannten (zum Teil auch rechts großen) Ing.-Planungsbüros auch weiterhin in GK. Wobei die verlustfreie Transformation zwischen GK und UTM zum Glück (auch in QGIS) kein Problem ist.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Damit möchte ich verdeutlichen, dass die Transformation von Vektordaten für manche QGIS-Anwender ein fast tägliches Problem ist. Und deshalb finde ich die Idee zur Implementierung solch einer Transformation als Kernfunktion in QGIS auch sehr unterstützenswert und könnte mir gut vorstellen, dass der QGIS-DE-Verein dies finanziell unterstützen könnte.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Viele Grüße<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Günter<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] <a href="https://lists.osgeo.org/pipermail/qgis-user/2021-February/047921.html">https://lists.osgeo.org/pipermail/qgis-user/2021-February/047921.html</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>