Re: GeometryField in OSMGeoAdmin

[Melvyn Sopacua]

On 22-8-2012 10:31, geonition wrote:

> I have a problem with GeometryField not showing the saved geometry in the
> admin interface. The problem is that the GeometryField has a type of
> 'GEOMETRY' when the value saved might have the type of e.g. 'POINT'.

The GeometryField is like the normal Field class: the base class for
actual fields you should be using in your model, like PointField. The
docs are not very clear on this issue.
--
Melvyn Sopacua

[geonition]

Hi,

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?

[Satinderpal Singh]

Hi,
I also start working on the the OSM in Geodjango and i am not much
familiar with it. I installed libraries like geos and starts a project
by following the instructions in the geodjango gide. But it only
tells, how to install libraries, my question is that how will i make
map in my project? Is there any documentation available for that?
Please tell me any possible way to deploy OSM to my project. Thanks in
advance.

--
Satinderpal Singh
http://satindergoraya.blogspot.in/

[Melvyn Sopacua]

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

[geonition]

Hi,

I do see your point Melvyn but my use case only requires to save different types of geometries and visualize them. Anything more usefull is just extra. This works fine when i build the map myself but the OpenLayersWidget has this geomtype restriction.

The complexity in saving geometries of different type to different fields instead of one comes from the additional logic of checking the geometry type and choosing the field/model accordingly, retrieving the geometry requires some additional logic, require one geometry to exist but only one --> additional logic.... I also agree that this might not be too hard or too complex but as the django website tells me "a framework for perfectionist with deadlines" where I a perfectionist on meeting deadlines feel like doing it the simplest way possible. But for now I solved the issue creating my own view and adding a link "view geometry" to the change list (the work amount mostly copy paste old stuff and simple examples).

Thanks for your help! At least now I know that the GeometryField is not supposed to work in the admin and the reasons behind it = we cannot do anything usefull with it.

[geonition]

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