Re: GeometryField in OSMGeoAdmin

Hi,

It is really convenient for me to use GeometryField for saving arbitrary geometry types and thus I only had the problem with using the Django admin in viewing these geometries.

I was able to solve this issue and like to post it here if anyone else sees some value in the solution, or on the other side criticism on why the solution is bad.

So I solved the issue creating a database view for each geometry type in PostGIS database:

CREATE OR REPLACE VIEW PolygonFeature AS SELECT * FROM geojson_rest_feature WHERE GeometryType(geometry) = 'POLYGON';

These SQL View creation code I set in sql/ folder to be loaded as initial data. For each view created I created a django model with managed = False

class PolygonFeature(FeatureBase):

    geometry = gismodels.PolygonField(srid = getattr(settings, 'SPATIAL_REFERENCE_SYSTEM_ID', 4326))

    

    class Meta:

        managed = False

        db_table = 'polygonfeature'

After this it is quite straight forward to register these models with the admin and everything seems to work fine except: 

1. syncdb has to be run twice as geodjango creates the geometry fields with the indexes and initial data is loaded before indexes.
   
2. ManyToMany Fields will still create manytomany tables for views
3. sqlflush and almost all other Django db management commands will break
4. Django tests will break

But otherwise everything is ok,

b.r.

Kristoffer

On Friday, August 24, 2012 2:24:44 AM UTC+3, Melvyn Sopacua wrote:

On 23-8-2012 10:41, geonition wrote:

> It is very convenient for me to use GeometryField as I can save any
> geometry type into the same field. The database logic will become more
> complex if I am required to create a separate table or field for e.g.
> points and linestrings.
>
> Still looking for a workaround, or is there a reason for me not to save all
> geometries into the same field?

Well, the reason is that it's kind of like XML. As long as it validates,
programs don't complain, but to do anything useful with it you have to
understand the structure and capabilities of the specific dialect.
And this is exactly what is biting you. As soon as you try to do
something useful with it, you need to know exactly what you stored. This
applies to the admin but certainly also to queries:
What exactly have you stored in relation to the rest of the fields? For
a house, you store a point, for a street a line string, for a
state/province a polygon - so what exactly is in the table and if you it
contains addresses does the geometry field apply to the address/house,
to the street or to the province?

I don't really understand the fear of using multiple tables, but I do
see many problems trying to make sense of your data if a field is
polymorphic. The reason you put stuff into a database is to organize
things so you can explore relationships between all the bits pieces.
That implies you need to cut things up first.
--
Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Zf1yUK2EfdYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.