three dimension linestrings
wibge
I'm trying to make a three dimensional linestringfield for lon, lat,
elevation, but only the first two dimensions are saving to the
database.
I have it declared like this:
class Trail(models.Model):
linestring = models.LineStringField(dim=3)
I removed the 2 dimension constraint on the table in the database. And
the coord_dimension is three for the table in geometry_columns.
I construct a linestring using a list of length three lists, which
I've inspected in python and is correct before the database save.
After the linestring is saved, viewing the Trail in psql with as_ewkt
and in python only shows that the first two dimensions were saved.
Any ideas what I'm doing wrong?
Thanks,
Anna
Robert Coup
I'm trying to make a three dimensional linestringfield for lon, lat,
elevation, but only the first two dimensions are saving to the
database.
Anna Hentzel
sql from my postgres log:
INSERT INTO "site_trail" ("name", "description", "begin_node_id",
"end_node_id", "distance", "ascent", "descent", "encoded_polyline",
"encoded_levels", "display", "start_time", "end_time", "pending",
"gps_file_id", "linestring") VALUES (E'ACTIVE LOG 005 004', E'', NULL,
NULL, E'656.607', E'71.136', E'99.976',
E'aXBjb0ZkanF9VWRBb0FCY0NsQWlDekJlQ2hCcUB4QF9DYkRtQ1J7QHRDc0J+QE4=',
E'Rj8/Pz8/Pz8/P0Y=', false, E'2009-06-25 04:15:51', E'2009-06-25
04:24:20', false, 192462,
ST_GeomFromWKB('\\001\\002\\000\\000\\000M\\000\\000\\000\\316[+\\220\\217\\026^\\300\\005B\\374\\015$\\254C@W\\016\\210k\\220\\026^\\300Z\\274X\\030"\\254C@\\362.r\\252\\220\\026^\\300\\247\\233\\037\\332"\\254C@\\353n\\236\\352\\220\\026^\\300\\232\\245\\256\\306#\\254C@\\370\\005O|\\220\\026^\\300\\350\\236\\032\\324#\\254C@WmH\\355\\217\\026^\\300\\304\\3107\\200#\\254C@\\275\\334\\314\\215\\216\\026^\\300\\356\\005f\\205"\\254C@\\246Av\\203\\215\\026^\\300\\322\\014\\230v
\\254C@#\\360,\\346\\214\\026^\\300\\336J\\300\\371\\036\\254C@a\\322\\316\\037\\211\\026^\\300\\246\\324%\\343\\030\\254C@\\236\\261\\324\\037\\206\\026^\\300Y\\263\\337$\\027\\254C@is\\234\\333\\204\\026^\\300}uU\\240\\026\\254C@\\253#G:\\203\\026^\\300\\000\\312:w\\026\\254C@\\261+\\322i\\202\\026^\\300l\\200-\\012\\026\\254C@\\203\\307\\0221\\200\\026^\\300\\211\\035\\327\\320\\027\\254C@\\036\\275\\206\\205\\177\\026^\\300\\326\\026C\\336\\027\\254C@\\327*f)~\\026^\\300_(`;\\030\\254C@\\345qbYz\\026^\\300\\234f&\\275\\024\\254C@\\274\\2605[y\\026^\\300y\\304\\215\\000\\023\\254C@?\\361\\255Yx\\026^\\300\\337a$\\305\\021\\254C@\\027a/\\271v\\026^\\300''\\024"\\340\\020\\254C@6\\337\\322{t\\026^\\300\\371\\021\\277b\\015\\254C@H\\361;\\227s\\026^\\300\\030\\215\\306\\353\\013\\254C@\\271g\\002\\352r\\026^\\300H\\207,w\\013\\254C@lW\\215\\312r\\026^\\300\\000\\255T\\253\\012\\254C@a\\016\\314\\033q\\026^\\300\\330\\225;\\330\\007\\254C@\\330*\\301\\342p\\026^\\300\\236\\203\\302\\373\\005\\254C@\\002
8xp\\026^\\3009
\\256A\\004\\254C@\\\\\\017\\025\\231o\\026^\\300\\216\\232\\012L\\002\\254C@E\\360\\277\\225l\\026^\\300~U.T\\376\\253C@d:\\031\\301k\\026^\\3001HUn\\375\\253C@\\014\\266l\\010i\\026^\\300QY\\003J\\371\\253C@\\233\\346\\035\\247h\\026^\\300\\201\\233
E\\370\\253C@\\217;\\000=h\\026^\\300\\223\\304\\222r\\367\\253C@H\\002h\\357g\\026^\\300\\355\\017\\224\\333\\366\\253C@6\\227v\\305g\\026^\\300\\224\\312\\312\\345\\365\\253C@T\\3363\\267g\\026^\\300\\364\\220\\204\\330\\364\\253C@\\351\\240\\246\\361f\\026^\\300\\306Fj\\353\\361\\253C@\\335h\\266\\341f\\026^\\300V}S\\375\\357\\253C@=\\376\\301vf\\026^\\3009\\016\\274Z\\356\\253C@\\357\\277:3f\\026^\\300\\316\\271%\\203\\355\\253C@\\032E
\\250d\\026^\\300\\334\\027+\\305\\351\\253C@y\\3614Od\\026^\\300N\\277\\237u\\350\\253C@>\\224h\\311c\\026^\\300\\220\\026\\302\\305\\345\\253C@\\332a\\002ma\\026^\\300\\375v\\310\\203\\343\\253C@Q"\\323\\353`\\026^\\300\\3026=\\203\\341\\253C@\\341\\313\\351W_\\026^\\300\\244\\301mm\\341\\253C@p\\206\\321b_\\026^\\300\\325\\325xD\\340\\253C@#\\301\\257\\354]\\026^\\300\\276\\205u\\343\\335\\253C@\\314\\375\\037qY\\026^\\300*\\236\\3041\\334\\253C@\\3233\\275\\304X\\026^\\300s\\204\\014\\344\\331\\253C@\\214+\\323\\324W\\026^\\300\\2657S|\\327\\253C@\\337C\\323#W\\026^\\300-Z\\200\\266\\325\\253C@\\310\\224\\017AU\\026^\\300\\276h\\217\\027\\322\\253C@\\202\\353\\345\\322S\\026^\\300H>e\\353\\317\\253C@\\333\\361\\313\\005S\\026^\\300\\352\\371\\344r\\315\\253C@\\377\\2348oR\\026^\\300\\323\\321\\273\\302\\314\\253C@H\\227\\355\\371P\\026^\\300\\341/\\301\\004\\311\\253C@\\014:!tP\\026^\\300\\377\\252\\310\\215\\307\\253C@\\251\\224\\215\\275M\\026^\\300\\307\\330\\011/\\301\\253C@9^\\201\\350I\\026^\\300\\033\\257\\212\\201\\277\\253C@\\325\\340\\307\\342H\\026^\\300{\\275\\373\\343\\275\\253C@\\376v~\\366H\\026^\\300S0\\031}\\273\\253C@\\237\\315\\005\\211H\\026^\\300\\330\\0068\\316\\267\\253C@Yl\\223\\212F\\026^\\300\\273o\\306z\\264\\253C@\\211\\366g\\365D\\026^\\300\\355\\377\\322X\\261\\253C@%\\276\\311%D\\026^\\300A2x\\363\\257\\253C@\\322\\360\\034\\200C\\026^\\300\\312\\001\\026T\\257\\253C@1*\\004\\315B\\026^\\300\\241\\376iY\\255\\253C@\\206\\215W\\305@\\026^\\300\\214\\2401\\223\\250\\253C@\\337|4\\346?\\026^\\300\\354\\200\\220\\321\\246\\253C@''\\242_[?\\026^\\300\\216~\\217U\\245\\253C@?W[\\261?\\026^\\300\\313\\326\\372"\\241\\253C@\\307\\177\\201
@\\026^\\300Ea\\274\\213\\234\\253C@\\2146"s@\\026^\\300\\237\\306b@\\233\\253C@z\\203y\\331@\\026^\\300X\\0060\\300\\231\\253C@b\\345\\206\\225@\\026^\\300\\237<,\\324\\232\\253C@',
4326))
Is that the information you wanted?
I tried doing an ST_asewkt on the linestring ST_GeomFromWKB, and only
got the first two dimensions. I also tried changing the ST_GeomFromWKB
to ST_GeomFromEWKB, and still only got two dimensions.
-Anna
Justin Bronn
> class Trail(models.Model):
> linestring = models.LineStringField(dim=3)
>
> I removed the 2 dimension constraint on the table in the database.
If you have `dim=3`, the constraint will be set properly automatically.
You may have had a previous definition that wasn't erased, thus
requiring you to manually alter the constraint. Regardless, that isn't
the source of your problems. I also assume you had `objects =
models.GeoManager()` in there as well :)
Robert Coup wrote:
> hmm, is GeoDjango using AsBinary()/AsText() instead of AsEWKB()/AsEWKT()
> somewhere? The former use "old" OGC spec geometries which didn't handle
> Z or M dimensionality.
GeoDjango doesn't 'wrap' the geometry output coming from the database in
any function call -- it takes the default value returned, which is HEXEWKB.
The root of the problem here is that GeoDjango doesn't officially
support 3D geometries yet. More specifically, until very recently GEOS
did not properly serialize the Z dimension in WKB -- see the following
tickets I filed:
http://trac.osgeo.org/geos/ticket/216
http://trac.osgeo.org/geos/ticket/217
Now that these are fixed, the biggest blocker is to fix certain
internals of GeoDjango to use 3D serialization when appropriate, because
currently the output of `str(geom.wkb)` is sent to the db, which only
outputs the 2D geometry:
In summary, getting 3D from PostGIS is OK, but GeoDjango only sends 2D
to database. This is obviously something that should be fixed for 1.2,
and I just opened a ticket:
http://code.djangoproject.com/ticket/11433
Attached to the ticket is a rough patch that will send 3D geoms to the
database. With it I was able to save a 3D geometry using the model
definition you provided. As you experiment more, share your experiences
in comments on the ticket, so I'll know of the gotchas when I actually
implement a robust fix.
Regards,
-Justin