Zugriff aus postgis Datenbanken mit FireDac

[MichaelP]

Ich nutze Firedac zum Zugriff auf Postgres Datenbanken.
Ich habe jetzt versucht auf Datenbanken mit der POSTGIS Erweiterung zuzugreifen. Jedoch erhalte ich beim Zugriff auf Datenbanken mit Geometriefeld immer eine Fehlermeldung.
Ist ein Zugriff mit FireDAC auf Tabellen mit Geometrie möglich?

UTF( Fehler
Hat jemand von eunch hiermit Erfahrungen?

Gruß
Michael

[jobo]

Zitat:

Zitat von MichaelP (Beitrag 1361273)

..Jedoch erhalte ich beim Zugriff auf Datenbanken mit Geometriefeld immer eine Fehlermeldung.
Ist ein Zugriff mit FireDAC auf Tabellen mit Geometrie möglich?

UTF( Fehler

Ich habe damit keine Erfahrung.
Beim Zugriff auf die Datenbank oder beim Zugriff auf eine spezifsiche Tabelle?

Soll ..UTF(Fehler.. die Fehlermeldung sein?

[RSF]

Ich gehe davon aus das der Zugriff auf eine Tabelle mit Geometriefelder gemeint ist.
Versuche einmal ein Testprojekt mit ZEOS Komponenten zu erstellen.
Benutze selber eine Postgres DB damit (aber ohne Geometrie, deshalb nur ein Versuch).
Ich hatte ein Projekt mit einer ADS Datenbank und dieses wollte ich mit FireDAC betreiben.
Ergebnis war, dass die Kommunikation zwischen ADS und FireDac Umständlich und Unvollständig war.
Danach mühevoll die originalen Advantage Komponenten per Hand installiert (kein Installer für Delphi Berlin vorhanden). Damit waren alle Funktionen verfügbar.

[MichaelP]

Habe jetzt eine andere fehlermeldung:
Firedac phys pg 1505 falscher komlexer Typ

Code:

CREATE TABLE public.points
(
  gid integer NOT NULL DEFAULT nextval('points_gid_seq'::regclass),
  osm_id character varying(11),
  "timestamp" character varying(20),
  name character varying(48),
  type character varying(16),
  geom geometry(Point),
  CONSTRAINT points_pkey PRIMARY KEY (gid)

Ich gehe davon aus das FIREDAC nicht mit den geometry felder umgehen kann

[jobo]

Ja, in welchen Typ sollte das eingetütet werden?
Du wirst es entweder zerlegen müsssen:
schau mal hier die "API"
http://postgis.net/docs/manual-2.0/r...etry_Accessors

Für Dich vielleicht hilfreich
st_x, st_y,
oder st_astextx (unter Geometry Outputs)

Ähnlich wirst Du wohl vorgehen müssen, wenn Du Werte eintragen willst.

Oder:
Alternativ musst Du den Point binär abfragen, seinen Aufbau kennen und dann in Delphi eine Zugriffsmethode bauen.
Hat wahrscheinlich auch schon mal irgendjemand irgendwo gemacht.

[RSF]

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.
PS: Ich habe nichts gegen FireDAC, aber in manchen anspruchsvollen Aufgaben macht diese einen unvollständigen und aufwendigen Eindruck.

[p80286]

Zitat:

Zitat von RSF (Beitrag 1361300)

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.

Rein theoretisch hast Du ja recht, aber in der Praxis können diese Komponenten ja alles, bis auf das, was eigentlich niemand bisher gebraucht hat.:roll:

Gruß
K-H

[jobo]

Zitat:

Zitat von RSF (Beitrag 1361300)

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.
PS: Ich habe nichts gegen FireDAC, aber in manchen anspruchsvollen Aufgaben macht diese einen unvollständigen und aufwendigen Eindruck.

Also ich weiß nicht, ob es in dem Fall für die Umsetzung eines Point Types so unwirtschaftlich wäre. Kommt auf die eigenen Fähigkeiten an.

Zum Rest Deines Beitrages:
Ich denke, dass man das so nicht sehen kann.
PostgreSQL ist sehr typstark. Man kann minütlich neue Typen produzieren und ausspucken. Wer soll die dann bitte alle in Delphikomponenten umwandeln?
Die Sache läuft anders. Die Erfinder der neuen Typen (wie z.B. point) liefern eine Zugriffs API mit, die mit bekannten Standardtypen arbeitet.
Nett oder?
Damit greift man dann bspw. nicht den Point ab, sondern dessen "Einzelteile".

Dass PostGIS oder der POINT Typ ein Flopp wird, kann ich mir auch kaum vorstellen.

Ich kann mir aber vorstellen, dass ein "POINT" oder andere Geometrietypen es irgendwann auch mal in das Standardrepertoire von Delphi schaffen, aber das dauert bestimmt noch.

[RSF]

Zitat:

Zitat von p80286 (Beitrag 1361319)

Rein theoretisch hast Du ja recht, aber in der Praxis können diese Komponenten ja alles, bis auf das, was eigentlich niemand bisher gebraucht hat.

Genau das ist was ich meine. Die allgemeinen „Universal- Komponenten“ (hier FireDac) versagen einfach wenn es spezifisch wird. Deshalb ist es besser (wirtschaftlicher) nicht das Fahrrad nochmal zu erfinden stattdessen spezialisierte darauf abgestimmte Komponenten zu verwenden/suchen.
Natürlich kann man selbst Hand anlegen. Wer die Zeit und Geduld hat.

@ jobo

Zitat:

Dass PostGIS oder der POINT Typ ein Flopp wird, kann ich mir auch kaum vorstellen.

Das PostGIS ein Flopp wäre habe ich nie geschrieben. Bitte immer schön bei der Wahrheit bleiben!
(Flopp stand im Bezug zu Komponenten und Funktionsinhalt)

Ronald

[jobo]

Zitat:

Zitat von RSF (Beitrag 1361346)

Die allgemeinen „Universal- Komponenten“ (hier FireDac) versagen einfach wenn es spezifisch wird. Deshalb ist es besser (wirtschaftlicher) nicht das Fahrrad nochmal zu erfinden stattdessen spezialisierte darauf abgestimmte Komponenten zu verwenden/suchen.

Ok, damit der TE nicht so lange suchen muss:
Welche Komponente empfiehlst Du?

Und nochmal zu Deiner Kritik (ich will es nicht tot reiten und ich sage auch nicht die Wahrheit, schon gar nicht die absolute). Ich kann es meinem Auto nicht vorwerfen, wenn die neuen hightech Niederqueschnitts- Nachhaltigkeitsreifen nicht auf die alten Felgen passen.

[RSF]

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

[mkinzler]

Zitat:

Zitat von RSF (Beitrag 1361364)

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

Das wird er hoffentlich. Aber trotzdem ist die Nachfrage von jobo legitim.

[RSF]

kurz die Suche bemüht:

PostgresDAC https://www.microolap.com/products/c...y/postgresdac/
Info zu den Feld Typen (Point, Box, Seg, Range) https://www.microolap.com/products/c...tom_fields.htm

SDK TatukGIS Developer Kernel
http://www.tatukgis.com/Products/Dev...scription.aspx

Ich hoffe das es dem TE Ersteller weiter hilft.

[MichaelP]

Hallo zusammen,
entschuldigt bitte dass ich mich solange nicht an der Diskussion beteiligt habe, bin aber zurzeit nicht immer in der Lage ins Netz zu kommen.
Die angegeben Komponenten scheinen eine mögliche Lösung zu sein. Hier sind jedoch wiedr zusätzliche Kosten erforderlich.
Dies ist in meinem Projekt schwer durchzusetzen.
Auch ein selbst implementieren ist sicherlich hier nicht wirtschaftlich.
Ich werde die angebenen Komponenten testen und bei Erfolg versuchen die Mittel locker zu machen.
Danke für eure Anmerkungen.

Noch mal zu den Geometrie-Typen im Allgemeinen:
- POSTGIS, Oracle Spatial usw. sind etablierte Techniken
- Geometriedaten sind nur mit diesen spezialisierten Typen und Funktionen zu nutzen


Gruß
Michael

[hanvas]

Zitat:

Zitat von MichaelP (Beitrag 1361997)

Hallo zusammen,
Die angegeben Komponenten scheinen eine mögliche Lösung zu sein. Hier sind jedoch wiedr zusätzliche Kosten erforderlich.
Dies ist in meinem Projekt schwer durchzusetzen.

Auch ein selbst implementieren ist sicherlich hier nicht wirtschaftlich.

Einen habe ich noch, und der ist kostenlos. MapWinGIS ist eine ActiveX Komponente (also nur Windows). Beim Erstellen der entsprechenden Units kommt es zu einigen Namenskonflikten die aber schnell gelöst sind. [1] MapWinGis unterstützt OGR und Datenbanken die OGR implementieren (PostGIS, Microsoft SQL Server, SpatiaLite, etc)

Zum Thema selbst programieren - eigentlich bräuchtest Du doch nur die "OGR Simple Feature Library" einbinden [2], die unterstützt explizit Postgis. Ist zwar in C++ geschrieben, die DLL hat aber auch ein C Interface.

hth

Ha-Joe

[1] https://github.com/MapWindow/MapWinGIS
[2] http://gdal.org/1.11/ogr/

vorbei.


Gruß
Michael[/QUOTE]

[jobo]

Zitat:

Zitat von RSF (Beitrag 1361364)

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

Mir ist bekannt, dass ich nicht der TE bin.
Ich habe dem TE bereits gezeigt, wie er ohne die Hilfe jeglicher Zusatzkomponenten die gewünschten Werte abfragen kann und noch viel mehr, konsistent aus POSTGIS heraus.
Da Du seine Frage nicht beantwortet hast, sondern die verwendeten Komponenten kritisiert hast und von besseren Möglichkeiten und Wirtschaftlichkeit geschrieben hast, habe ich das aufgegriffen und Dich lediglich gefragt, was konkret an Komponenten zu nennen wäre.