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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: GeometryField in OSMGeoAdmin
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. -- 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/-/vYUmYE8Iu2wJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: GeometryField in OSMGeoAdmin
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 post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: GeometryField in OSMGeoAdmin
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/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: GeometryField in OSMGeoAdmin
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? On Thursday, August 23, 2012 2:27:48 AM UTC+3, Melvyn Sopacua wrote: > > 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 > -- 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/-/WJauvt8Cs1QJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: GeometryField in OSMGeoAdmin
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 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
GeometryField in OSMGeoAdmin
Hi, 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'. This leads to that the OpenLayersWidget will set the value as empty. I do not know why the widget do this, but my question is is there a workaround to make the geometry show as it should in the admin interface? This is the line causing problems for me in OpenLayersWidget: if value and value.geom_type.upper() != self.geom_type: value = None -- 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/-/Y0pZr__NSbgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
