On Jul 12, 2010, at 19:28 , David Winslow wrote: > On 07/12/2010 01:15 PM, Gabriel Roldan wrote: >> On 7/12/10 4:48 AM, Andreas Hocevar wrote: >> >>> On Jul 12, 2010, at 06:45 , Gabriel Roldan wrote: >>> >>>> >>>> Aside: the whole question arises from the fact that we're storing >>>> the center point of the map in 4326, then who performs the >>>> transformation to Map's CRS. Wouldn't make more sense to store the >>>> map's center point in the Map's CRS to start with? (I don't know >>>> about the internals of this design decision so excuse me if I'm >>>> missing something obvious.) >>>> >>> I was thinking along the same lines when I wrote my initial reply, >>> but considered the fact that the coordinates are stored in 4326 as >>> engraved in stone. But you are right, as long as we don't search maps >>> (only layers) by location, storing the map bounds/center in map CRS >>> coordinates would solve the problem, and make map persistence 100% >>> compatible with the gxp viewer. >>> >> that would be (_IMHO_) step in doing it the right way. And it doesn't >> preclude the ability to make map searches by map bounds in the future, >> if we need to. >> There may be a couple options: >> - A Map may have it's own metadata record, where lat lon bounds is >> already there to be used on spatial searches >> - we may have our own database of maps, where we could search by >> something like toWGS84(mapbounds) overlaps my bounds. >> >> Gabriel >> >> >>> -Andreas. >>> >> >> > This sounds good to me, we can just punt on the reprojection-in-python > issue for now. We do still need to handle a reprojection/migration on > the live site, but someone (me maybe?) can script that from outside the > Django webapp. > > Here's the current set of fields on a Map: > title = models.CharField > abstract = models.CharField > contact = models.CharField > > featured = models.BooleanField > endorsed = models.BooleanField > > zoom = models.IntegerField > center_lat = models.FloatField > center_lon = models.FloatField > owner = models.ForeignKey > > I guess we should rename center_lat and center_lon to center_x and > center_y, and add a display_srid field to track the display projection?
+1 on adding display_srid, or just srid. > > On the other hand, as long as we are migrating all this stuff, we could > replace the (center + zoomlevel) model with just a bbox. Zoom levels > seem a bit vague in the face of arbitrary projections, unless I am > mistaken. Opinions? Not as long as we always assume a maxExtent for each projection we use (e.g. the recommended maxExtent for the projection as advertised in the EPSG database). In that case, a context of projection+center+zoom will give us well defined zoom levels. And with the planned GWC integration, we need to make a maxExtent assumption on a per-projection basis anyway. Also, there is a behavioral difference between center+zoom and bbox. The former guarantees a zoom level, while the latter guarantees a visible extent independent of the map size on the screen. At this point, gxp.Viewer only supports the former. The reason for this is the behavior of OpenLayers.Map.zoomToExtent, which guarantees the whole extent to be visible. This tends to zoom out the map by one zoom level with every load-save cycle, unless the aspect ratio of the bbox is exactly the same as the map on the users's screen. The disadvantage of storing center+zoom is that on small maps, users won't see the full extent. The disadvantage of storing bbox ist that the map might look different depending on the screen size due to scale dependent styling. For the sake of simplicity, I'm in favor of going with center+zoom, but I'm willing to make the necessary changes to gxp.Viewer if extent should also be supported. Regards, Andreas. -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
