Opened 15 years ago

Closed 14 years ago

#11168 closed (invalid)

postgis geometry alternatively seen as linestring then multilinestring

Reported by: anonymous Owned by: nobody
Component: GIS Version: 1.0
Severity: Keywords: GEOS API, Postgis
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Django 1.0.2 final on MacOS 10.5 python 2.5
GEOS Framework 3.0.1-1

see django shell example below

RegionHydro is a GeometryField from a postgis table containing linestrings and multilinestrings

>>> r=RegionHydro.objects.get(id=19)
>>> c=r.getCoursDo()
>>> c
[<CoursDo: La Meuse>, <CoursDo: Canal de l'Est Branche-Nord>]
>>> c[1].geom
<MultiLineString object at 0x28208c4>
>>> c[1].geom
<LineString object at 0x28209b4>
>>> c[1].geom
<MultiLineString object at 0x28208c4>
>>> c[1].geom
<LineString object at 0x28209b4>

Change History (6)

comment:1 by anonymous, 15 years ago

sorry,

I meant : CoursDo model geom attribute is a GeometryField from a postgis table containing linestrings and multilinestrings

to make it simple, I have a multilinestring object that is alternatively seen as a linestring then a multilinestring by the GEOS API

hope it's clear enough...

comment:2 by jbronn, 15 years ago

Please provide the geometry data (in WKT format) so I can attempt to reproduce.

comment:3 by ludifan, 15 years ago

I solved the problem by forcing all the linestrings to multilinestrings in the postgis table and setting the field type to MultiLineString in django.
I'm not sure the problem comes from the geometry itself but may be from the type of the data table in postgis (GEOMETRY).

You could eventually download the data here: http://services.sandre.eaufrance.fr/data/zonage/Hydrographie2008/arcinfo/FranceEntiere/courdo00.e00.zip
and import it to postgis using ogr:

set PGCLIENTENCODING=LATIN1
ogr2ogr -f PostgreSQL "PG:dbname=eau_france user=postgres password=postgres" -nlt GEOMETRY cours_d_eau.shp

(you have to force type geometry)

then see if you can reproduce the thing

this was my model definition for this feature:

class CoursDo(models.Model):
    id = models.IntegerField(db_column="ogc_fid", primary_key=True)
    toponyme = models.CharField(db_column="toponyme", max_length=127)
    codehydro = models.CharField(db_column="code_hydrographique", max_length=8)
    classification = models.CharField(db_column="classification", max_length=1)
    geom = models.GeometryField(db_column="wkb_geometry", srid=32767)
    objects = models.GeoManager()
    
    class Meta:
        db_table = "cours_d_eau"
        verbose_name_plural = r"Cours d'eau"
        verbose_name = r"Cours d'eau"
        
    def __unicode__(self):
        return self.toponyme.strip()

comment:4 by Jacob, 14 years ago

Triage Stage: UnreviewedAccepted

comment:5 by Jacob, 14 years ago

Triage Stage: AcceptedDesign decision needed

in reply to:  3 comment:6 by jbronn, 14 years ago

Resolution: invalid
Status: newclosed

Replying to ludifan:

I solved the problem by forcing all the linestrings to multilinestrings in the postgis table and setting the field type to MultiLineString in django.
I'm not sure the problem comes from the geometry itself but may be from the type of the data table in postgis (GEOMETRY).

You could eventually download the data here: http://services.sandre.eaufrance.fr/data/zonage/Hydrographie2008/arcinfo/FranceEntiere/courdo00.e00.zip
and import it to postgis using ogr:

set PGCLIENTENCODING=LATIN1
ogr2ogr -f PostgreSQL "PG:dbname=eau_france user=postgres password=postgres" -nlt GEOMETRY cours_d_eau.shp

(you have to force type geometry)

The data link is for ArcInfo E00 format, I found the shapefile data here: http://services.sandre.eaufrance.fr/data/zonage/Hydrographie2009/arcgis/FranceEntiere/cours_d_eau.shp.zip. I loaded it up, and it's a larger dataset (> 125K rows).

I don't think there's a bug here. Specifically, I don't think you're ordering your QuerySet, and what you think is the same model is actually a different one -- in other words, you're seeing a different geometry on a separate record. Each time you're evaluating c[1].geom you're hitting the database, and if you're not ordering your SQL there's no guarantee it'll return the same record each time. See Ordering Data from the Django Book.

If you can boil it down to a distinct, reproducible test case I'll be glad to reopen the ticket -- otherwise, I'm closing as invalid.

Note: See TracTickets for help on using tickets.
Back to Top