Closed araichev closed 10 years ago
For geometric queries, it would also be handy for stop objects to have a 'geometry' attribute (or some name like that) that's a PointField object, trip objects to have a geometry attribute that's a LineStringField object, and route objects to have a geometry attribute that's a MultiLineStringField object, the union of its trip line strings. What do you think?
Working on this feature. Stops and ShapePoints already have a point
field. After the changes:
geometry
LineStringField that is the sequence of ShapePoints,geometry
LineStringField which is the same as the Shape, or is the sequence of Stops through StopTimes,geometry
MultiLineStringField which is the collection of Trip linesThe geometry
fields are populated at the end of a GTFS import, and updating the point
of a Stop or a ShapePoint will cause a cascading update of related Shapes, Trips, and Routes. We'll see if that is useful and performant.
Cached geometries are included in v0.3.1
I'm a newbie to GeoDjango, so please correct me if i'm misunderstanding something.
Would it be a good idea to add a LineStringField attribute to the Shape class in
shape.py
that encodes the geometry of the shape so that then one could make geometric queries such as "Get me all the trips in bounding box blah"?