As the title suggests, provide the means by which the user can connect to a remote PostGIS enabled PostgreSQL database, and select table(s) to load in the map stack to be viewed/edited like any other layer type/source.
Thank you,
Eric Jarvies
Please sign in to leave a comment.
Connecting to PostGIS is fine using the Actual ODBC drivers, but I can't figure out how to map the hexadecimal geometry stored in PostGIS to something that Cartographica understands. For example, Postgres spits out this: 0101000020E6100000A350815942E541C0C471C73852B76540 when, if selected as st_x, st_y is -35.79108733, 173.72878684.
I've read the manual & searched online and am a bit stuck. Help?
As of 1.4.2, Cartographica does not support Geometry columns via ODBC. We have this on the road map, and will post more information when test versions are available.
What about adding the ability for Cartographica to import 'the_geom' coordinates when using tabular data import feature? This would at least make it less painful to export data from PostgreSQL/PostGIS and import said data into Cartographica. Right now one must create LATITUDE and LONGITUDE columns in said database table prior to exporting said data because Cartographica only provides the option to import tabular data if it already contains X and Y coordinate fields. Currently Cartograpica EXPORTS 'the_geom' when doing a PostgreSQL format export... so it would be nice if it could also read 'the_geom' column of a tabular data import.
Unfortunately, it's not as simple as just decoding the _the_geom_ binary blob. Our ODBC support handles a single table at a time, and _the_geom_ contains the x and y coordinates as well as an SRID. Unfortunately, the SRID is a pointer into another table in the same database which contains the Coordinate Reference System information. So, if we were to pull out the coordinates from the data in the ODBC connection, we'd basically have to pull it out without regard to the CRS. We can certainly do that, but the long-term plan is to integrate better knowledge of PostGIS, so we can pull the SRID (CRS) information out as well, thus importing the data in the correct coordinate reference system.
If people are comfortable with pulling the geometry columns in without CRS information for the time being and then having to use **Layer > Set Layer's Projection** to set the projection if it doesn't match our guess, then we can do something like that in shorter order.